[Zope3-Users] Re: SqlAlchemy

[Jürgen Kartnaller]

Hi catonano.

As the developer of the z3c.zalchemy package let me give you a short 
introduction to zalchemy :

Zope3 contains a transaction mechanism which allows to plug in as many 
transaction managers as you like. The main purpose of the zalchemy 
package was to integrate SQLAlchemy into Zope3's transaction handling.
Actually the package provides this by implementing a data manager which 
joins Zope3's transactions when needed.
"when needed" in this case means, any time a session is requested from 
zalchemy via the getSession method a data manager for the current thread 
is activated.
The hole complexity of Zope3's transaction system is now behind the scenes.

See also my notes below.

And don't forget to read the README in z3c.zalchemy ;)

Jürgen


catonano wrote:
> Hello zopers,
> 
> well this email is going to be quite long, I'm sorry I have many things 
> to say
> 
> I saw the Zope 3 book, particulary the mapping (adapting) between the 
> persistent objects defined there (a messageboard and a message objects) 
> and some ftp files (and folders).
> 
> Now, I'd like to do the same with some, say, objects that are in a MySql 
> database. I would love to realize a folders/files hierarchy that's 
> mapped on my relational database !
> 
> I saw SqlAlchemy. It's impressive. I took a look at the Zalchemy code 
> too, just to see wether I could borrow something.
> 
> I made a plan about how to achieve all this. I would like to expose it 
> here and ask you, kind zopers, wether it's sane or there's something BIG 
> I'm missing.
> 
> Because in the Zalchemy code I saw something I don't understand so I 
> started to fear that there is something big I'm missing, indeed.
> 
> So, my plan is:
> 
> 1) introduce all my tables and relationships between them. Something 
> like users = Table('users', metadata, autoload = True)

If you use zalchemy, make sure you use z3c.zalchemy.metadata

> 
> and then overriding some table property where needed, also introducing 
> some relationships, all what needed
> 
> 2) define some interfaces as in the Zope 3 book, introducing containers 
> and contained objects
> 
> 3) define implementation classes for the interfaces that in their 
> methods do something similar to what I saw in SQLAlchemyContainer, for 
> example, which is, say,
> 
>    def __setitem__(self, name, item):
>         session = z3c.zalchemy.getSession()  #in my case I still don't 
> know where I'll take the session from

If you use zalchemy this is how to get the session, that's it, no other 
case!

>         session.save(item)
>         session.flush([item])
> 
> 4) adapt these components to files, as in the book example
> 
> Could this be a good plan ?
> 
> Because in the Zalchemy code I saw a strange class, that is:
> 
> class AlchemyDataManager(object):
>     """Takes care of the transaction process in zope.
>     """
>     implements(IDataManager)

This is the transaction manager mentioned above.

> 
> shall I take care of this transaction process too ?

Of course :
- it makes your life easier because zalchemy takes care of it
- it makes sure nothing is commited in case of errors or on write conflicts

> 
> Because I know nothing about it and saw not so many docs about the 
> internal Zope3 machinery.
> 
> Thanks so much for any hint
> Bye
> Catonano