[Zope3-Users] Re: FW: ZODB storage ways

[David Pratt]

Hi Jurgen. This is good news. I was also looking at doing this over the 
past couple of days using SQLOS and Brian's work as the model. Can we 
ensure this is ZPL as in the rest of Zope. SQLAlchemy is an important 
integration for Zope. Please let me know when SVN has been set up. I am 
quite interested in this (and also looking at getting SQLAlchemy into 
Five to eliminate need for zsql in Zope2). Again Brian has code in SQLOS 
that should be helpful to make this happen.

Regards,
David

j.kartnaller wrote:
> Hi David.
> 
> Yesterday I implemented an integration for SQLAlchemy into zope.
> 
> Currently it contains a data manager which handles zope transactions and
> a container for mapped sqlalchemy objects.
> 
> I will setup a svn repository this week.
> 
> There are some open configuration things.
> I started with some ZCML configuration directives to be able to setup
> the database in ZCML (not very popular these days :).
> 
> Jürgen
> 
> David Pratt wrote:
> 
>> Hi Pete. I have been looking at SQLAlchemy for Zope3. Can you advise 
>> how  you are using this with zope's transactions. It seems that there 
>> are some folks using SQLAlchemy with Zope3 for sure. I am hoping to 
>> see a few things formalized somewhere or some work on assembling a 
>> small package like SQLOS did for SQLObject. I think SQLAlchemy is a 
>> more feature rich ORM and am simply looking for a way to use it in Zope3.
>>
>> Regards,
>> David
>>
>> Pete Taylor wrote:
>>
>>> 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 <jtaylor at thig.com> wrote:
>>>
>>>>
>>>> -----Original Message-----
>>>> From: zope3-users-bounces at zope.org 
>>>> [mailto:zope3-users-bounces at zope.org] On
>>>> Behalf Of Marco Mariani
>>>> Sent: Monday, April 03, 2006 1:14 PM
>>>> To: Andreas Jung; reinhold.strobl at gmx.net; zope3-users at zope.org
>>>> 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.
>>>>>>
>>>>>
>>>>> one solution:
>>>>>
>>>>> <http://hathawaymix.org/Software/PGStorage>
>>>>
>>>>
>>>> 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 
>>>> row is
>>>> not a (record|instance).. the structure we manipulate objects in 
>>>> ZODB is
>>>> 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 
>>>> its
>>>> 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
>>>> effort?
>>>>
>>>>
>>>> _______________________________________________
>>>> Zope3-users mailing list
>>>> Zope3-users at zope.org
>>>> http://mail.zope.org/mailman/listinfo/zope3-users
>>>
>>>
>>>
>>>
>>>
>>> -- 
>>> "All guilt is relative, loyalty counts, and never let your conscience
>>> be your guide."
>>>   - Lucas Buck, American Gothic
>>> _______________________________________________
>>> Zope3-users mailing list
>>> Zope3-users at zope.org
>>> http://mail.zope.org/mailman/listinfo/zope3-users
>>>
> 
> _______________________________________________
> Zope3-users mailing list
> Zope3-users at zope.org
> http://mail.zope.org/mailman/listinfo/zope3-users
>