[Shr-Devel] New features in opimd queries

Al Johnson openmoko at mazikeen.demon.co.uk
Thu Aug 27 11:41:42 CEST 2009


On Thursday 27 August 2009, Thomas Zimmermann wrote:
> 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...

Is there any documentation for date related opimd entries? I'm worried that if 
timestamps are being used for date/time storage there will be no way to store 
timezone.



More information about the community mailing list