|
Sphinx
Community
Services
Misc
 Subscribe in a reader
|
Is mediumint usable?
Common forum |
1 | 2 | 3 | 4 | 5 | ... |
224 | 225 | 226 | 227 | next »» | Create new thread
|
babs
Name: Doug
Posts: 7
|
2008-08-28 06:46:21
| reply!
Is a mediumint mysql id acceptable even if it's a 24 bit integer, not a 32-bit one? There
are no duplicates but is there another problem with using a 24 bit integer? Thanks.
|
|
Arantor
Name: Pete Spicer
Posts: 4441
|
to: babs, 2008-08-28 12:07:51
| reply!
> Is a mediumint mysql id acceptable even if it's a 24 bit integer, not a 32-bit one? There
> are no duplicates but is there another problem with using a 24 bit integer? Thanks.
I believe Sphinx will internally convert it to 32 bit when indexing, but if the query
outputs a number that fits inside the 24-bit range and you don't have more than 24-bits
worth of documents, I don't see there should be a problem.
|
|
shodan
Name: Andrew Aksyonoff
Posts: 3966
|
to: babs, 2008-08-28 16:12:19
| reply!
> Is a mediumint mysql id acceptable even if it's a 24 bit integer, not a 32-bit one? There
> are no duplicates but is there another problem with using a 24 bit integer?
It's OK. Sphinx does not care about the column type. As long as it pulls strings that
convert to unique integers from SQL, you're fine, whatever is the underlying column type.
|
|
babs
Name: Doug
Posts: 7
|
to: shodan, 2008-08-28 17:00:17
| reply!
> It's OK. Sphinx does not care about the column type. As long as it pulls strings that
> convert to unique integers from SQL, you're fine, whatever is the underlying column type.
Then why does the documentation state, "ALL DOCUMENT IDS MUST BE UNIQUE UNSIGNED NON-ZERO
INTEGER NUMBERS (32-BIT OR 64-BIT, DEPENDING ON BUILD TIME SETTINGS)." ?
Am I misunderstanding something, or should statement that be revised? Thanks.
|
|
|
markus
Name: Markus
Posts: 43
|
to: babs, 2008-08-28 17:27:54
| reply!
> > It's OK. Sphinx does not care about the column type. As long as it pulls strings that
> convert to unique integers from SQL, you're fine, whatever is the underlying column type.
>
> Then why does the documentation state, "ALL DOCUMENT IDS MUST BE UNIQUE UNSIGNED NON-ZERO
> INTEGER NUMBERS (32-BIT OR 64-BIT, DEPENDING ON BUILD TIME SETTINGS)." ?
>
> Am I misunderstanding something, or should statement that be revised? Thanks.
I'm also confused by this sentence. :( My doubt is related to the scope of this
restriction. Is it within the scope of a set of indexes (behind a distributed index) or
within the scope of a particular Sphinx instance?
In example, one single Sphinx instance with the following indexes:
- Unique document ids for a_main1 + a_main2 + a_delta + a_dist.
- Unique document ids for b_main1 + b_main2 + b_delta + b_dist.
Is it possible for Sphinx to manage these sets of indexes? ...or that restriction applies
here as well? :-/
Sorry, for hacking the thread, but it seems related to the cause of the confusion behind
that sentence.
|
|
|
shodan
Name: Andrew Aksyonoff
Posts: 3966
|
to: babs, 2008-08-28 17:45:26
| reply!
> Then why does the documentation state, "ALL DOCUMENT IDS MUST BE UNIQUE UNSIGNED NON-ZERO
> INTEGER NUMBERS (32-BIT OR 64-BIT, DEPENDING ON BUILD TIME SETTINGS)." ?
>
> Am I misunderstanding something, or should statement that be revised? Thanks.
Its formally correct, though possibly confusing.
What Sphinx (currently) sees from MySQL is a text string. That string must contain an
unique unsigned integer that fits into 32 (or 64) bits.
And while that condition is met we don't really care just *how* the string was built -
was it SELECTed from 24bit mediumint, or CONCATtenated from several other strings, or
whatever.
|
|
shodan
Name: Andrew Aksyonoff
Posts: 3966
|
to: markus, 2008-08-28 17:46:29
| reply!
> within the scope of a set of indexes (behind a distributed index)
Only within every single physical index.
|
|
markus
Name: Markus
Posts: 43
|
to: shodan, 2008-08-28 17:52:52
| reply!
> > within the scope of a set of indexes (behind a distributed index)
>
> Only within every single physical index.
Sweet! Thanks! :)
|
|
babs
Name: Doug
Posts: 7
|
to: shodan, 2008-08-28 18:01:23
| reply!
I see, thanks.
> Its formally correct, though possibly confusing.
>
> What Sphinx (currently) sees from MySQL is a text string. That string must contain an
> unique unsigned integer that fits into 32 (or 64) bits.
>
> And while that condition is met we don't really care just *how* the string was built -
> was it SELECTed from 24bit mediumint, or CONCATtenated from several other strings, or
> whatever.
|
Common forum |
1 | 2 | 3 | 4 | 5 | ... |
224 | 225 | 226 | 227 | next »» | Create new thread
|
