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
