On 8/26/09, Sebastian Krzyszkowiak <seba.d...@gmail.com> 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 False. 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. And: > 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 dos _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community