Re: [Shr-Devel] New features in opimd queries
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. -131 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
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] New features in opimd queries
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. -131 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.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] New features in opimd queries
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. -131 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
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] New features in opimd queries
On Thursday 27 August 2009 12:07:09 Sebastian Krzyszkowiak wrote: 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. Correct. Epoch(UTC) should be the native format on dbus API level, but remember to include a flag that indicates whether timestamps are always following local time or stick to the timezone they have been entered (which could be handy at times). UI can convert this to fancy things. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] New features in opimd queries
On 8/27/09, Michael 'Mickey' Lauer mic...@vanille-media.de wrote: On Thursday 27 August 2009 12:07:09 Sebastian Krzyszkowiak wrote: 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. Correct. Epoch(UTC) should be the native format on dbus API level, but remember to include a flag that indicates whether timestamps are always following local time or stick to the timezone they have been entered (which could be handy at times). UI can convert this to fancy things. :M: There already is Timezone field which does exactly that :) -- Sebastian Krzyszkowiak dos ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
