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

_______________________________________________
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Reply via email to