[Shr-Devel] New features in opimd queries

[Thomas Zimmermann]

Am Donnerstag 27 August 2009 11:41:42 schrieb Al Johnson:
> 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.
>
Currently there is no documentation. I thought to store the timestamp as UTC.
And it looks like dos1 stores timestamps too in opimd-notes.

Any suggestion how to query dates through DBUS? Perhaps we can add a date 
datatype to DBUS, i think that would be the best way :)

Thomas