[Zope3-Users] Re: Other SQLAlchemy thoughts, Zope transaction manager, etc...
Jeff Shell wrote: On 4/6/06, Martin Aspeli [EMAIL PROTECTED] wrote: I, for one, am really excited by this [sqlalchemy / zalchemy]. I really hope that Zope 3 will have a somewhat consistent story for RDBMS access that (a) uses technology not invented in Zope alone (b) is scalable and robust and (c) is documented with patterns that people can easily follow. It's been too long. :) I agree. I'm independently testing some methods of SQLAlchemy / Zope integration. There's a lot about SQLAlchemy to like. Separation of definition and implementation is a natural approach for a Zope user. From what I can gather, SQLAlchemy does a lot of things similarly to the ZODB when it comes to data mapping: its objectstore/unit of work system tracks clean and dirty objects (and deletes, etc), I guess similar to the _v_changed property in the ZODB. When used with the objectstore session's begin/commit/rollback functions, only the items changed after the begin are committed. It uses thread locals heavily to store some of the core work-tracking items, so a call to 'objectstore.get_session()' is often enough. objectstore.begin() is just a wrapper like: def begin(): get_session().begin() with the same for commit, is_dirty, and so on. Confusingly, there are a couple of notions of 'sessions', and a couple of notions of 'commit'. On the 'engine' objects themselves (them what work with the dbapi connections and database vendor specifics) have both 'commit()' and 'do_commit()' (same for begin and rollback). 'engine.commit()' calls 'engine.session.commit()' which decrements a counter that has been incremented each time a begin() call was made. When the counter reaches 0 (free of nesting), it calls back to engine.do_commit(), which is what calls commmit() on the dbapi connection and sends the command to MySQL. sqlalchemy's mapping layer is built on top of this core layer, and is the get_session() stuff I mentioned above. It also supports nesting (with an option to commit each time commit is called, like a save point, or just when the nesting is back to 0). It has a begin() option which sets a starting point. Any changes made prior to begin() are lost. begin() returns a transaction object with commit / rollback. What I've been toying with is how to work with the SQLAlchemy's concept of a transaction manager (which does not do two-phase commit) along with Zope's. Pulling ideas from different sources, I've played with the idea of: * Subclassing from an engine (like mysqlengine) and replacing its do_* methods which are what actually call commit(), rollback() on the RDBMS, and using a DataManager to call those actions directly. * Still letting the objectstore do its commits which are where the 'sql is sent over the wire' in the main commit() phase of the Data Manager. [first phase - send data; second phase - send 'commit' command] * Using just one proxy engine (using a subclass of sqlalchemy's proxy) and a simple utility / zcml directive that connects the engine only once. The subclassed version allows for a factory to be used instead of a DBAPI uri (mysql://...), so that I could use my custom MySQL Engine. SQLAlchemy's threading and pool management should work fine with Zope 3. And... well, it _kindof_ works. But I'm buggered by how to tap into Zope's transaction.begin(), which actually looks like it's going away soon (it's marked as deprecated). I'm guessing I can use the beforeTraverseEvent and manually join, like 'zalchemy' does. But I don't like that option. I'd rather use transaction.begin() itself (I looked at Synchronizers, but couldn't really figure out how to make those work since a synchronizer is bound to just one thread). There are no other hooks that I can see where I can register my engine/mapping/whatever in SQLAlchemy to automatically join a transaction at the beginning (mostly so that it's just one concept, whether I'm using Zope's transaction stuff in a web request or in a command line tool). That's why I use beforeTraverseEvent. It's the only option I found. I also have no idea how the synchronizer can be used if there is no hook to add it to a thread. Alternately, I was looking at the zope.app.publication.zopepublication.ZopePublication. That's where the traversal events are fired off, and also where the main transaction begin/commit/abort work happens. But no event is fired off in beforeTraversal (which is called only once, at the beginning of publication, and shouldn't be confused with BeforeTraverseEvent which is called for names traversed along the way), and subclassing and registering new publications and factories for a new Publication just to add (perhaps) one line of code felt grossly disproportionate when all I'm interested in is a new transaction was just started, let this third party transaction system start up too. Right Documentation on the 'transaction' package is scant. I can't tell if it's primarily an abstraction of a useful tool from the ZODB, or if it maybe wants to be a
[Zope3-Users] Install problem with Zope 3.2.1
Hi, I tried installing Zope 3.2.1. configure worked ok, but when ran make I got the following: /usr/bin/python install.py -q buildTraceback (most recent call last): File "install.py", line 28, in ? context.initialize() File "/usr/src/Zope/Zope-3.2.1/Support/zpkgsetup/setup.py", line 121, in initialize self.scan(depname, pkgdir, reldir) File "/usr/src/Zope/Zope-3.2.1/Support/zpkgsetup/setup.py", line 211, in scan self.scan_package(name, directory, reldir) File "/usr/src/Zope/Zope-3.2.1/Support/zpkgsetup/setup.py", line 225, in scan_package pkginfo = package.loadPackageInfo(name, directory, reldir) File "/usr/src/Zope/Zope-3.2.1/Support/zpkgsetup/package.py", line 101, in loadPackageInfo pkginfo = read_package_info(directory, reldir) File "/usr/src/Zope/Zope-3.2.1/Support/zpkgsetup/package.py", line 166, in read_package_info data_files[:] = expand_globs(directory, reldir, data_files) File "/usr/src/Zope/Zope-3.2.1/Support/zpkgsetup/package.py", line 303, in expand_globs raise ValueError(ValueError: filename pattern '*-configure.zcml' doesn't match any filesmake: *** [build] Fejl 1 I can configure and build Zope 3.2.0 and 2.9.1 without any problems. I'm using Gentoo Linux and python 2.4.2. Thanks, Kim ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Other SQLAlchemy thoughts, Zope transaction manager, etc...
On Thu, Apr 06, 2006 at 08:04:11PM -0600, Jeff Shell wrote: I'd rather use transaction.begin() itself (I looked at Synchronizers, but couldn't really figure out how to make those work since a synchronizer is bound to just one thread). In sqlos._transaction, we are creating and registering a synchronizer in the __init__ method of a zope.thread.local sub-class. The tests tell me it actually works for more than just the main thread. -- Brian Sutherland Metropolis - it's the first movie with a robot. And she's a woman. And she's EVIL!! ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Time for a Decimal field type in zope.schema?
Perhaps this is an old topic, although I've done searches. I've seen the brief discussion about security proxies and the Decimal type on zope3-users, but (to zope3-dev) what about getting it added to the zope.schema as a first-class field type? So we can have auto-generated HTML forms and such? Has anyone already done this, in some Zope3 branch or private development? If not, is there any good reason it should not happen? Must Zope3 support Python versions prior to the introduction of the Decimal type? I'm willing to tackle it and make a submission, otherwise. -Jeff ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: Other SQLAlchemy thoughts, Zope transaction manager, etc...
Jeff Shell wrote: On 4/6/06, Martin Aspeli [EMAIL PROTECTED] wrote: I, for one, am really excited by this [sqlalchemy / zalchemy]. I really hope that Zope 3 will have a somewhat consistent story for RDBMS access that (a) uses technology not invented in Zope alone (b) is scalable and robust and (c) is documented with patterns that people can easily follow. It's been too long. :) I agree. I'm independently testing some methods of SQLAlchemy / Zope integration. There's a lot about SQLAlchemy to like. Indeed, it's quite well modularized, and easy to plug into. From what I can gather, SQLAlchemy does a lot of things similarly to the ZODB when it comes to data mapping: its objectstore/unit of work system tracks clean and dirty objects (and deletes, etc), I guess similar to the _v_changed property in the ZODB. When used with the objectstore session's begin/commit/rollback functions, only the items changed after the begin are committed. It uses thread locals heavily to store some of the core work-tracking items, so a call to 'objectstore.get_session()' is often enough. objectstore.begin() is just a wrapper like: def begin(): get_session().begin() with the same for commit, is_dirty, and so on. Confusingly, there are a couple of notions of 'sessions', and a couple of notions of 'commit'. On the 'engine' objects themselves (them what work with the dbapi connections and database vendor specifics) have both 'commit()' and 'do_commit()' (same for begin and rollback). 'engine.commit()' calls 'engine.session.commit()' which decrements a counter that has been incremented each time a begin() call was made. When the counter reaches 0 (free of nesting), it calls back to engine.do_commit(), which is what calls commmit() on the dbapi connection and sends the command to MySQL. sqlalchemy's mapping layer is built on top of this core layer, and is the get_session() stuff I mentioned above. It also supports nesting (with an option to commit each time commit is called, like a save point, or just when the nesting is back to 0). It has a begin() option which sets a starting point. Any changes made prior to begin() are lost. begin() returns a transaction object with commit / rollback. What I've been toying with is how to work with the SQLAlchemy's concept of a transaction manager (which does not do two-phase commit) Which is unfortunate and actually a showstopper for me. However it's fixable. SQLAlchemy's author said he didn't do two-phase commit for now because the python DBI layer didn't support it. It'll need to be extended or worker around. along with Zope's. Pulling ideas from different sources, I've played with the idea of: * Subclassing from an engine (like mysqlengine) and replacing its do_* methods which are what actually call commit(), rollback() on the RDBMS, and using a DataManager to call those actions directly. * Still letting the objectstore do its commits which are where the 'sql is sent over the wire' in the main commit() phase of the Data Manager. [first phase - send data; second phase - send 'commit' command] * Using just one proxy engine (using a subclass of sqlalchemy's proxy) and a simple utility / zcml directive that connects the engine only once. The subclassed version allows for a factory to be used instead of a DBAPI uri (mysql://...), so that I could use my custom MySQL Engine. SQLAlchemy's threading and pool management should work fine with Zope 3. And... well, it _kindof_ works. But I'm buggered by how to tap into Zope's transaction.begin(), which actually looks like it's going away soon (it's marked as deprecated). I'm guessing I can use the beforeTraverseEvent and manually join, like 'zalchemy' does. But I don't like that option. I'd rather use transaction.begin() itself (I looked at Synchronizers, but couldn't really figure out how to make those work since a synchronizer is bound to just one thread). There are no other hooks that I can see where I can register my engine/mapping/whatever in SQLAlchemy to automatically join a transaction at the beginning (mostly so that it's just one concept, whether I'm using Zope's transaction stuff in a web request or in a command line tool). Alternately, I was looking at the zope.app.publication.zopepublication.ZopePublication. That's where the traversal events are fired off, and also where the main transaction begin/commit/abort work happens. But no event is fired off in beforeTraversal (which is called only once, at the beginning of publication, and shouldn't be confused with BeforeTraverseEvent which is called for names traversed along the way), and subclassing and registering new publications and factories for a new Publication just to add (perhaps) one line of code felt grossly disproportionate when all I'm interested in is a new transaction was just started, let this third party transaction system start up too. IMO the proper way to do any of this stuff would be to write a Connection and DB implementation, and write a mount point
Re: [Zope3-Users] Time for a Decimal field type in zope.schema?
On Apr 7, 2006, at 8:35 AM, Jeff Rush wrote: Perhaps this is an old topic, although I've done searches. I've seen the brief discussion about security proxies and the Decimal type on zope3-users, but (to zope3-dev) what about getting it added to the zope.schema as a first-class field type? So we can have auto-generated HTML forms and such? Has anyone already done this, in some Zope3 branch or private development? Not as far as I know. If not, is there any good reason it should not happen? Must Zope3 support Python versions prior to the introduction of the Decimal type? Not as far as I know. I'm willing to tackle it and make a submission, otherwise. +1 Gary ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] understanding security
Hi, On Fri, Apr 07, 2006 at 03:33:28PM +0200, Achim Domma wrote: Hi, I'm just learning Zope and have a question regarding the security model: Do I understand it right, that I do not grant a permission to a principal on a certain object instance? I only grant a permission to use a certain interface!? You can either grant permissions to principals (or groups/roles) globally. Those permissions can be used in multiple ways: * To protect Views. You can only access views you have permissions for (e.g. browser:page ... ) * To protect attributes/methods of classes (*not objects*) (class ...required interface=...) * To define, who is allowed to modify certain attributes (class ...required set_schema=... ) Additionally you may grant permissions (and role memberships) on a per object (*not per class*) basis ( using e.g. the grant.html-View) which effects only a single object. Regards, Frank PS: @zope-gurus: Please correct me if I'm wrong, I' still learning, too :-) ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] understanding security
Frank Burkhardt wrote: Do I understand it right, that I do not grant a permission to a principal on a certain object instance? I only grant a permission to use a certain interface!? You can either grant permissions to principals (or groups/roles) globally. Those permissions can be used in multiple ways: * To protect Views. You can only access views you have permissions for (e.g. browser:page ... ) * To protect attributes/methods of classes (*not objects*) (class ...required interface=...) * To define, who is allowed to modify certain attributes (class ...required set_schema=... ) I can follow to this point. That's how I understand Zope security until now. Additionally you may grant permissions (and role memberships) on a per object (*not per class*) basis ( using e.g. the grant.html-View) which effects only a single object. That's what I was looking for, but don't know how to do. For I example: I want to let a user create an object (i.e. a message in a message board). All users with a certain role (i.e. Admins) should be able to edit the new object, but the creating user should also be able to edit it. So I have to give him the persmission to edit. How can I do something like that? regards, Achim ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Install problem with Zope 3.2.1
On Fri April 7 2006 05:24, Kim L. Jacobsen wrote: I tried installing Zope 3.2.1. configure worked ok, but when ran make I got the following: I'm using Gentoo Linux and python 2.4.2. I can't help with the error, but Zope 3 is in Portage and can be installed with a simple 'emerge zope' if you put net-zope/zope in package.keywords. Zope 3.2.1 isn't there yet, only 3.2.0. However, making a 3.2.1 ebuild overlay is simple enough and works for me. -- Ron ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] understanding security
Achim, Take a look at homefolder in the trunk. You can find it here: http://svn.zope.org/Zope3/trunk/src/zope/app/homefolder/ It does what you want to do. On Fri, 07 Apr 2006 16:50:50 +0200, Achim Domma wrote Frank Burkhardt wrote: Do I understand it right, that I do not grant a permission to a principal on a certain object instance? I only grant a permission to use a certain interface!? You can either grant permissions to principals (or groups/roles) globally. Those permissions can be used in multiple ways: * To protect Views. You can only access views you have permissions for (e.g. browser:page ... ) * To protect attributes/methods of classes (*not objects*) (class ...required interface=...) * To define, who is allowed to modify certain attributes (class ...required set_schema=... ) I can follow to this point. That's how I understand Zope security until now. Additionally you may grant permissions (and role memberships) on a per object (*not per class*) basis ( using e.g. the grant.html-View) which effects only a single object. That's what I was looking for, but don't know how to do. For I example: I want to let a user create an object (i.e. a message in a message board). All users with a certain role (i.e. Admins) should be able to edit the new object, but the creating user should also be able to edit it. So I have to give him the persmission to edit. How can I do something like that? regards, Achim ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] embedding a form in a viewlet
based on help that Stephan, Gary, and Alen were able to give me, I managed to embed a form in a viewlet to edit child objects of the current context, on the same page. I threw out some documentation on what I did and how I got there just in case anyone else runs into the same issue. http://baldtrol.blogspot.com/ -- All guilt is relative, loyalty counts, and never let your conscience be your guide. - Lucas Buck, American Gothic ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] MySQL Connection Closed Errors
What is the best way to manage MySQL connections? Were using the mysqldba and frequently get the following errors when calling queryForResults: File /home/djohnson/Zope-3.2.0/build/lib.linux-i686-2.4/zope/app/rdb/__init__.py, line 408, in queryForResults raise DatabaseException(str(error)) DatabaseException: Shouldn't load state for 0x01b3 when the connection is closed Were implementing in the following fashion: self.connection = zapi.getUtility(IZopeDatabaseAdapter, name) query = select * from contacts results = queryForResults(self.connection,query) Its a local database on a machine with very little load, so connection issues should not be a regular problem. -- David Johnson ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
