[Shr-Devel] New features in opimd queries

[Kero van Gelder]

> If you set _at_least_one to some non-false value, opimd will switch
> into "at least one field" mode. Query {'Name':'dos', 'Content' :
> 'Test', '_at_least_one': True} will return entries with Name = dos
> *or* Content = Test. Without '_at_least_one', opimd checks if entry
> matches to all fields in query (so Name = dos *and* Content = Test) .
> 
> Now you can also query values greater or lower than specified. To do
> that, you can use '_gt_Timestamp' or '_lt_Timestamp' fields (replace
> Timestamp with whatever you want). Those field names are equal to
> '_float_gt_Timestamp', '_float_lt_Timestamp'. There are also
> '_int_gt_Timestamp' and '_int_lt_Timestamp' fields which you can use
> with integer values, when you don't need float. Maybe it gives some
> performance speed-up ;)

Is that _gt_20090101: birthday or _gt_birthday: 20090101 ?

(and if the latter, I think _birthday_gt: 20090101 reads better since
it is infix notation; I find prefix notation ambiguous to read)

I have no idea why you want to make a distinction between floats and
int on dates. Either your underlying format is based on floats, or it
isn't. and I would need to know whether your "int" is a day, or a second.
Instead, I'd like you to convert my query to the underlying format, so I do
not have to worry about it, ever.

In my experience, using OS native time is no too bad. -1<<31 is 
December 1901, there are not too many things I'd like to put in a
pim suite, that happen(ed) before that. And I guess anything non OS native
is likely slower than OS native. That's assuming the comparison of timestamps is
taking more CPU cycles than parsing my timestamp-string in the first place.

Bye,
Kero.

___
How can I change the world if I can't even change myself?
  -- Faithless, Salva Mea