New features in opimd queries

Sebastian Krzyszkowiak seba.dos1 at
Thu Aug 27 12:07:09 CEST 2009

On 8/26/09, Sebastian Krzyszkowiak <seba.dos1 at> wrote:
> Hi!
> I looked today into implementing new features in opimd queries. Since
> ages special field "_limit" was supported, limiting number of results
> returned by query. Now there are more special fields :)
> 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 ;)
> Also, sorting is implemented on opimd side. To specify by which field
> you want to sort, use '_sortby' field. Default order is ascending, you
> can change it to descending by setting '_sortdesc' to non-false value.
> Recently opimd also was teached how to use libphone-utils, so it can
> do phone resolving correctly. So now quering {'Phone':'tel:663123456'}
> will return contact with phone '+480663123456' (country code, national
> prefix and other friends has to be configured in libphone-utils. In
> SHR there is SHR Settings module for that, you can do that also
> manually in /etc/phone-utils.conf. To use that features, you have to
> have python-phoneutils package installed.
> Work on "inteligent queries" was also started. Now when you query
> {'Name':'dos'} in for instance Contacs, and after that new contact
> with name 'dos' arrives, ContactAdded signal is emitted in that query
> path. GUI apps can make use of that to dynamicly update screens.
> New domains were added - Notes, Tasks, Dates. Notes domain seems to be
> finished. Tasks domain isn't used anywhere yet, so I don't know how
> usable it is ;) But basics should work, as it's based on
> GenericDomain, as every domain now (except Messages, but that's just
> because I'm too lazy ;)). I also don't know much about Dates domain.
> Heinervdm and morphis said that they will work on it, so let's see
> what they'll do :)
> Also - old feature, just to remind - opimd sends MessageUpdated and
> MessageDeleted signals (change Messages to Contact, Call, Note or
> whatever else). When using opimd interface for handling SMS, you get
> CSM (concatenated short messages) support absolutely for free
> And one thing about opimd-utils: package in shr-unstable was divided
> into opimd-utils, opimd-utils-data, opimd-utils-cli and
> opimd-utils-notes. opimd-notes is now included in shr fat image and
> opimd-cli is in both lite and fat images (will be there after next
> image build, now they're available in repo). I consider opimd-notes as
> finished in functionality, only some tweak ups due to async support
> and dynamic refreshing screen on new data has to be done :)
> frameworkd with all that features is already in shr-unstable
> repositories. I'll try to document all those features in FSO docs
> soon.
> Enjoy and happy coding! :)
> --
> Sebastian Krzyszkowiak
> dos

Today I implemented new feature: you can enable case sensitive sorting
by setting _sortcasesens field to non-false value. Default value is

So now answers to questions ;)

> Is that _gt_20090101: birthday or _gt_birthday: 20090101 ?

_gt_Birthday: 20090101
(but I prefer saving dates in UNIX timestamp format, as it's already
done in Messages domain)

> 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.

opimd itself don't know what format fields are supposed to have. I
implemented _int_gt and _int_lt versions only because I thought using
them on int values could be faster that casting to float. Maybe I
wrong - then I can remove both _float and _int versions and leave only
_gt and _lt casting to float ;)

> 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.
> 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...

In my opinion we should use unix timestamps and that's what i'm
implementing in my test apps.

> 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.

Just use Timezone field for that, as it's done now in Messages domain :)

Sebastian Krzyszkowiak

devel mailing list
devel at

More information about the community mailing list