When data is fed into Baloo, integer variables
will be added to the Document, while uints
will fall through to the standard path used
for strings, and consequently will be added
to the TermGenerator. Treat uints like
integers.
Details
Details
- Reviewers
bruns - Group Reviewers
Baloo - Commits
- R293:f6f9ecb2a17e: Treat uints the same as ints
Diff Detail
Diff Detail
- Repository
- R293 Baloo
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Comment Actions
Disclaimer: this is really just from looking at the code without knowing much about the internals of Baloo.
While KFileMetaData is currently not using uints anywhere, doubles are definitely there.
Comment Actions
I think support for non-integers is useful in general, but there are a few things we should consider:
Currently, only integral numbers can be searched. For floats, we definitely want Less/Greater matches to work, exact matches for floats are not very useful.
As you are referring to the TermGenerator, I suppose the (float) variant gets converted to something like "-5.73", which is mangled by the TermGenerator to something like "X42-5.73", i.e. dropping the sign? (See D17284)
Ideally, this were backed by some unit tests. The comparision test can be added to the postingdbtest, but AFAICS there are currently no tests covering Baloo::Result
Comment Actions
Okay, so there is more work to do for floats. What about then reducing this patch to uints for now, and doubles are added when everything else is in place?
I have something in the pipeline for the Result class, which I added for figuring out how string lists are handled, I can probably post that tomorrow. I could then extend the test for floats
Comment Actions
Yes, UInt should be fine (actually, all our current integral numeric properties are unsigned).