[Bitpim-devel] database.basedataobject implementation issue

[d***@netzero.com]

I was working on storing the caledar data into the new database and ran into an issue:

dict['start']=[ { 'date': (y,m,d), 'time': (h,m) } ]

which bombed out since the leave value is a list/tuple. I suppose I could try:

dict['start']=[ { 'year': y, 'month': m, 'day': d, 'hour': h, 'min': m } ]

but that seems kinda silly. Roger, what's your take on this?

-Joe Pham


________________________________________________________________
NetZero Gift Certificates
Give the gift of Internet access this holiday season.
http://www.netzero.com/give

[Roger Binns]

Post by d***@netzero.com
dict['start']=[ { 'date': (y,m,d), 'time': (h,m) } ]

Does this work?

dict['start']=[ y, m, d, h, m]

Post by d***@netzero.com
Roger, what's your take on this?

The biggest elephant in the room is that we have no strategy for dealing with
timezones. Currently everything is stored in the local timezone. That has
worked wonderfully so far as it is exactly how the phones operate.

I am thinking we may need to replace the dates/time with a string and various
convenience methods to deal with them. The format should always be able to
cope with missing hours and minutes. It should also have a timezone which
can either be conventional timezones or None, meaning local time. (Note that
we do not convert local time to a timezone. That causes grief.)

As for the other types in the database, our eventual get out mechanism is to use
the Python pickle format for some items. (I guess that addresses your earlier
emails about user defined types :-)

That means I need to make two changes when I update the database:

- A dictindirect type where the top level item can be a dict

- A way of marking values so that they get pickled and unpickled.
Probably the easiest thing is to require them to have a particular
base class. We can use this mechanism to store these "rich"
date/time objects.

Any more work for me :-?

Roger

[d***@netzero.com]

Post by Roger Binns
Does this work?
dict['start']=[ y, m, d, h, m]

Had not tried it, but I suspect it would not work since the database needs a list of dicts.

How about using the format specified in ISO8601:
'YYYYMMDDThhmm' or just 'YYYYMMDD'

It even specifies start/end time events:
'YYYYMMDDThhmm/YYYYMMDDThhmm' (or without the time components)

-Joe Pham


________________________________________________________________
NetZero Gift Certificates
Give the gift of Internet access this holiday season.
http://www.netzero.com/give

[Roger Binns]

Post by d***@netzero.com
'YYYYMMDDThhmm' or just 'YYYYMMDD'
'YYYYMMDDThhmm/YYYYMMDDThhmm' (or without the time components)

And where does the (optional) timezone go? We will definitely need
timezone information to deal with syncing with other data sources
such as Outlook and ical.

That is why I am suggesting we use a new data type whose class deals
with all these issues. The objects can be saved/restored using
pickling.

Roger

[d***@netzero.com]

Post by Roger Binns
And where does the (optional) timezone go?

The optional timezone info can be specified either local time, UTC, or number of hours:min relative to UTC:

local time: YYYYMMDDThhmm
UTC: YYYYMMDDThhmmZ
EST: YYYYMMDDThhmm-0500

-Joe Pham



________________________________________________________________
NetZero Gift Certificates
Give the gift of Internet access this holiday season.
http://www.netzero.com/give

[Roger Binns]

Post by d***@netzero.com

Post by Roger Binns
And where does the (optional) timezone go?

local time: YYYYMMDDThhmm
UTC: YYYYMMDDThhmmZ
EST: YYYYMMDDThhmm-0500

The issue is that we need an internal representation format.
This internal format is never seen by users, only the coders. As
developers we need a rich type that lets you easily get at the various
fields in various combinations, as well as ask questions such as
does this correspond to an all day event or is there a specific time.

The database on the other hand is where the data type needs to be
stored persistently. It is dumb in that it only deals with
string, int, float, and dicts and lists under some circumstances.

Our choices are:

1 Use a really low level representation such as the string format
above and have a set of functions elsewhere that can extract the
parts and answer the questions

2 Use a higher level class, and add support to the database for
pickling. This makes the value opaque to the database code, but
lets it be very rich. Care will need to be taken to maintain
compatibility over time so that the old pickled values can
be read in newer code and various other version variations.

It seems like doing #1 would be the best at the moment, and only resort
to #2 when forced. This will keep the database human readable for the
forseeable future :-)

You may want to start a time module that provides the functions for
the string. I suggest calling it bptime.

Roger