On Sep 30, Davide Alberani <[EMAIL PROTECTED]> wrote:
> Many users asked to switch from SQLObject to SQLAlchemy.
[...]
> If someone with a little SQLAlchemy experience wants to help...
Here we are!
I've committed the first draft to the CVS, in the main trunk.
It comes with full support for _both_ SQLObject and SQLAlchemy (both
0.4 and 0.5 branches).
If someone wants to help, but has problems accessing the CVS,
I can send a tarball/zip.
the 'sql' data access system now takes a new optional argument: useORM,
which can be a string ('sqlalchemy' or 'sqlobject') or a list/tuple
of strings (to specify the order of preference).
By default, SQLObject is used first, with SQLAlchemy used as a
fall-back.
As far as I can tell, a database created with SQLAlchemy is perfectly
accessible using SQLObject, and vice-versa (more tests required).
At insert time (imdbpy2sql.py) there are no performances drawbacks at
all, since it uses the ORM only to get tables and columns names (data
insertion was always done using the executemany() method of a cursor).
Fetching the data, SQLAlchemy (well... the adapter) is ~70% slower,
but I suppose there's place for a lot of optimization. Anyway, it's
noticeable but still fully usable.
Technical aspects:
- the vast majority of the old (SQLObject-only) code is still here,
because I preferred to adapt SQLAlchemy to the code that was already
in place.
- the dbschema module now contains a generic schema (used to represent
our database structure, complete with indexes and so on), and some
generic functions.
- the objectadapter module generates SQLObject classes based on the
above mentioned schema.
- the alchemyadapter module includes many classes used to adapt
SQLAlchemy to SQLObject; obviously ONLY for the aspects of SQLObject
that we need: a complete adapter would be a crazy thing to realize.
This is the module that needs more attention: as said I know next to
nothing of the SQLAlchemy internals, and I may have done many things
wrong. Moreover I've already encountered some problems, marked with
the usual TODO/FIXME/XXX tags.
If some wants to help, please concentrate on this module!
Open issues (in regards of SQLAlchemy):
- I really don't know if I've handled in the correct way the connection
to the database.
- RowAdapter has both __getattr__ and __setattr__ methods; the latter
is used only on a veeery rare occasion (updating .imdbID columns for
name, char_name, title and company_name tables).
Unfortunately I can't really think of a better solution.
- title.title, name.name, char_name.name and company_name.name columns
are TEXT if created with SQLObject, but VARCHAR(255) (unicode) if
created with SQLAlchemy.
It's that way because with SQLAlchemy you can't specify, creating an
index, to consider only the first N chars of a TEXT field.
Some (very few, to tell the truth) entries are truncated.
Maybe it's possible to fix this "manually".
- SQLite, used with SQLAlchemy, seems to cause some problems here and there.
Enjoy!
--
Davide Alberani <[EMAIL PROTECTED]> [PGP KeyID: 0x465BFD47]
http://erlug.linux.it/~da/
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Imdbpy-devel mailing list
Imdbpy-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/imdbpy-devel
