#2731 closed bug (invalid)
Only Int-32 and Int-64 attributes are indexed
Reported by: | humdinger | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | File Systems/BFS | Version: | R1/pre-alpha1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
On vmware, hrev27404. (hope this is the right Trac category.)
When I index an attribute with "mkindex -t int" I cannot tell if it's int-8, 16, 32 or 64. So I guess it doesn't matter...
However, querying for an Integer attribute only works if the attribute type is Int-32 or Int-64. So I take it 8 nd 16 bit integers are not indexed? Or is the Tracker's Find... buggy?
Change History (2)
comment:1 by , 16 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:2 by , 16 years ago
Ok, I see.
Wouldn't it be a good idea to have mkindex a) check with the MIME database to verify the type of the attribute (maybe even do some automagic typing if the attribute exists in the MIME database) b) mention in the --help that 32bit is "int" and 64bit is "llong"? As long as there's only a commandline app to do the indexing, end users are exposed to it. Many (myself included :) ) don't know what llong means. BTW, is the type "time" missing in mkindex help?
It may even be a good idea to have a text appear in the FileType preferences when you choose the type 8 or 16 bits, that this type cannot be indexed/queried.
BFS only supports indexing int-32 and int-64. You'll have to use "int" for int-32, and "llong" for int-64, otherwise the index won't be correctly used.
int-8 & int-16 cannot be indexed, just use int-32 instead.