[Bitpim-devel] Database now used for phonebook

[Roger Binns]

I have just committed the code that uses the database for the phonebook.
I've tested the heck out of it all and everthing is littered with assert
statements. However there are bound to be some issues. Please shout if
you find any anomalies.

You can use the developer console if you want to see what is actually in
the database. The following commands are available from the developer
console:

tables()
rows(tablename)
sql(command)

You have access to the database.Database object as db. You can get a dict
representation of the phonebook using:

db.getmajordictvalues("phonebook")

You'll probably want to do this:

import common
common.prettyprintdict(db.getmajordictvalues("phonebook"))

Now I just have to get around to implementig Undo and change
history ....

Roger

[d***@netzero.com]

If I were to save the calendar dict in database, should I also save the 'categories' list similar to what you've done for the phonebook?

-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
If I were to save the calendar dict in database, should I also save the
'categories' list similar to what you've done for the phonebook?

There is only one categories list. It is managed by the phonebook.

You can use the stuff in pubsub (ie REQUEST_CATEGORIES and ALL_CATEGORIES
to get the values).

Roger

[d***@netzero.com]

Currently, you limit the type of a database dict value to be either instrinsic or buffer, are you considering also allowing dict or basedataobject type, ie. dict['key']={ 'key1': 'val1', ... }

-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
Currently, you limit the type of a database dict value to be either instrinsic
or buffer, are you considering also allowing dict or basedataobject type,
ie. dict['key']={ 'key1': 'val1', ... }

I didn't have nay need for that so I didn't implement it :-)

I guess you need it to do the repeat setting. I can't see any
cleaner way of expressing things so the database should definitely
be extended for this case.

I'll add a new indirect type 'dictindirect' that should do the
trick.

Note that when reading back the dataobjectfactory only provides the
container object for the outermost record. That means that
inside items come back as plain dicts. I guess this should
be fixed as well at some point.

Roger

[d***@netzero.com]

Post by Roger Binns
I'll add a new indirect type 'dictindirect' that should do the
trick.

Sweet. This may be considered as a future enhancement, but are you also considering some sort 'plug-in' capability such that other coders can define their own types and handling routines to translate/convert them into one of your database-compatible types (or something your db routines can handle)?

-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
This may be considered as a future enhancement, but are you also considering
some sort 'plug-in' capability such that other coders can define their own
types and handling routines to translate/convert them into one of your
database-compatible types (or something your db routines can handle)?

I'd rather not, preferring the KISS principle.

Can you show any compelling examples of it being needed?

Roger

[d***@netzero.com]

Post by Roger Binns
Can you show any compelling examples of it being needed?

Not really. I just thought it was something cool to have :-)

-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
Can you show any compelling examples of it being needed?

Not really. I just thought it was something cool to have :-)

In theory having some magic code could make things easier (eg
something could automatically hide wallpaper in files in the
filesystem, and when reading back from the database go off
and recover their contents).

However it soon leads to layers of complexity and leads to being
hard to understand what is going on. It is notable that several
large projects stick to C even though you could get similar
improvements from C++ (eg Samba, Linux kernel, Gnome).

The good news is that Python is *really easy* to refactor
so rather than proactively adding in layers of indirection and
coolness, it is easier to wait until we actually need them :-)

Roger