I agree with Marco that the use case i can most readily imagine for
needing to tie zodb objects back to an rdb is to allow people to run
reports or get at historical data in more conventional ways...
I've had to make allowances for that in a number of projects i'm
currently working on for zope3... this may not be immediately
helpful, but sqlalchemy (http://www.sqlalchemy.org) provides a really
nice way to simply write your classes as you would, tie the relevant
elements back to an rdb with a simple mapper on the class, without
restricting your class design too much.
as an example, i have a BTreeContainer derivative that maps a number
of it's Bool, TextLine, and Date attributes to a msyql database, while
letting other objects it contains be treated just like any other
BTreeContainer. So long as you tie the sqlalchemy's sessions in
correction and commit when you know the zodb will be committing, it's
been pretty seamless so far, for my experience.
i admit, tables i'm using are not complex, nor are the objects that
are tied to them, so your mileage may vary...
On 4/3/06, Pete Taylor <[EMAIL PROTECTED]> wrote:
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Marco Mariani
Sent: Monday, April 03, 2006 1:14 PM
To: Andreas Jung; [EMAIL PROTECTED]; email@example.com
Subject: Re: [Zope3-Users] ZODB storage ways
Andreas Jung wrote:
I am searching for a way to change transparently the storage of ZODB
from file-base to a relational database. In general, Zope books
state, that this is possible.
Unfortunately, pickles are not even remotely a SQL datatype... :)
I guess many people just want a SQL backend to allow queries from third
parties in the way they are used to.
If I do NOT want to be able to modify the data via SQL, and performance
is not a concern (not huge systems..), wouldn't it be better to "adapt"
:-) the data structure to a DBMS backend, with sane natural keys, but
without the hassle of advanced integrity constraints?
After all, as Joe Celko says, a table is not a (file|class) and a
not a (record|instance).. the structure we manipulate objects in
not always the one we would like to use to perform SQL queries.
I mean, not dumping the whole ZODB on the DBMS, but run a few SQL
commands whenever an object "the clerks are interested into" changes
state or data, gets deleted or whatever.
This, and adding a dump function to wipe out and recreate the SQL DB
should we have the need (structure changes, whatever).
I've yet to look at zope events, maybe it can be done without too much
Zope3-users mailing list
"All guilt is relative, loyalty counts, and never let your conscience
be your guide."
- Lucas Buck, American Gothic
Zope3-users mailing list