[Shr-Devel] New features in opimd queries

[Thomas Zimmermann]

Am Donnerstag 27 August 2009 00:08:44 schrieb 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.
I think Sebastian implemented these gt and lt functions because of me. I need 
them for opimd-dates.
The Problem with a timestamp string is: what format does it have? In this case 
we have to include the format defenition into the API. Then it's a lot easier 
to use unix-timestamps they are easy to parse and compare...

Thomas