problem with commits in SQLAlchemyDA
Hi all, I wanted to use SQALchemyDA with a standalone Zope 2.11 (we only depends on CMFCore). i tried to get it up using easy_install, which is pretty straightforward, once removed the incompatible zope.component package needed in the dependencies. It ends up with the following installed packages (skipping zope 3 components) : zope.sqlalchemy-0.4-py2.4.egg z3c.sqlalchemy-1.3.10.1-py2.4.egg SQLAlchemy-0.5.5-py2.4.egg Products.SQLAlchemyDA-0.4.1-py2.4.egg At first glance, this works well, but the DA actually can't manage to commit any sql requests (I try only for insert in Mysql and postgres but I'm sure it's always true). This is quite an unexpectable behavior for a DA. I think the problem is related to this thread I found on tg-trunk newsgroup : http://www.mail-archive.com/turbogears-trunk@googlegroups.com/msg07302.html There is a misleading comment in the docstring of zope.sqlalchemy.datamanager.join_transaction speaking of a DirtyAfterFlush SessionExtension, which I never seen except in plone code. In the last I finally manage to make it work by monkey patching SQLAlchemyDA itself this way : try : from Products.SQLAlchemyDA import da from z3c.sqlalchemy import getSAWrapper, createSAWrapper if '0.4.1' in da.__file__ and not hasattr(da.SAWrapper, '_patched__wrapper_property') : da.SAWrapper._patched__wrapper_property = da.SAWrapper._wrapper def _always_invalidated_wrapper(self): """The property '_wrapper' patched by CFENet to correct what seems to be a bug in SQLAlchemyDA which prevents any commit.""" from zope.sqlalchemy.datamanager import STATUS_INVALIDATED if self.dsn: try: return getSAWrapper(self.util_id) except ValueError: return createSAWrapper( self.dsn, forZope=True, transactional=self.transactional, engine_options={'convert_unicode' : self.convert_unicode, 'encoding' : self.encoding}, extension_options={'initial_state': # the whole # point is here STATUS_INVALIDATED}, name=self.util_id) return None da.SAWrapper._wrapper = property(_always_invalidated_wrapper) except ImportError : pass Anyone has any insights about this problem, any comments on my solution, did it have been reported and corrected, or am I simply missing something ? -- _____________ Maric Michaud
I do not see any reference to mark_changed you have to call it before any transaction.commit() to tell the zope transaction machinery that it has to commit you changes also. robert Maric Michaud schrieb:
Hi all,
I wanted to use SQALchemyDA with a standalone Zope 2.11 (we only depends on CMFCore).
i tried to get it up using easy_install, which is pretty straightforward, once removed the incompatible zope.component package needed in the dependencies.
It ends up with the following installed packages (skipping zope 3 components) : zope.sqlalchemy-0.4-py2.4.egg z3c.sqlalchemy-1.3.10.1-py2.4.egg SQLAlchemy-0.5.5-py2.4.egg Products.SQLAlchemyDA-0.4.1-py2.4.egg
At first glance, this works well, but the DA actually can't manage to commit any sql requests (I try only for insert in Mysql and postgres but I'm sure it's always true).
This is quite an unexpectable behavior for a DA.
I think the problem is related to this thread I found on tg-trunk newsgroup :
http://www.mail-archive.com/turbogears-trunk@googlegroups.com/msg07302.html
There is a misleading comment in the docstring of zope.sqlalchemy.datamanager.join_transaction speaking of a DirtyAfterFlush SessionExtension, which I never seen except in plone code.
In the last I finally manage to make it work by monkey patching SQLAlchemyDA itself this way :
try : from Products.SQLAlchemyDA import da from z3c.sqlalchemy import getSAWrapper, createSAWrapper if '0.4.1' in da.__file__ and not hasattr(da.SAWrapper, '_patched__wrapper_property') : da.SAWrapper._patched__wrapper_property = da.SAWrapper._wrapper
def _always_invalidated_wrapper(self): """The property '_wrapper' patched by CFENet to correct what seems to be a bug in SQLAlchemyDA which prevents any commit.""" from zope.sqlalchemy.datamanager import STATUS_INVALIDATED if self.dsn: try: return getSAWrapper(self.util_id) except ValueError: return createSAWrapper( self.dsn, forZope=True, transactional=self.transactional, engine_options={'convert_unicode' : self.convert_unicode, 'encoding' : self.encoding}, extension_options={'initial_state': # the whole # point is here STATUS_INVALIDATED}, name=self.util_id) return None
da.SAWrapper._wrapper = property(_always_invalidated_wrapper)
except ImportError : pass
Anyone has any insights about this problem, any comments on my solution, did it have been reported and corrected, or am I simply missing something ?
robert rottermann a écrit :
I do not see any reference to mark_changed you have to call it before any transaction.commit() to tell the zope transaction machinery that it has to commit you changes also. robert
In fact, what I understood is that zope.sqlalchemy, by default, bypasses the commit if status is not manually set as 'changed' (see the docstring I quoted in my previous mail). The alternative is to build the SessionExtension with initial_state == STATUS_INVALIDATED. My point is that it should be the default for a DA, as it is intended to be used mainly by zsql methods which doesn't do nothing to the transaction state. Maybe I wasn't clear but the patch works well with my existing zsql code. -- _____________ Maric Michaud
Maric Michaud schrieb:
robert rottermann a écrit :
I do not see any reference to mark_changed you have to call it before any transaction.commit() to tell the zope transaction machinery that it has to commit you changes also. robert
In fact, what I understood is that zope.sqlalchemy, by default, bypasses the commit if status is not manually set as 'changed' (see the docstring I quoted in my previous mail). The alternative is to build the SessionExtension with initial_state == STATUS_INVALIDATED.
My point is that it should be the default for a DA, as it is intended to be used mainly by zsql methods which doesn't do nothing to the transaction state.
Maybe I wasn't clear but the patch works well with my existing zsql code.
it is a longtime that i worked with zsql methods. however I think the difference is, that zsql handles transactions itself. it wraps every zqls method in a start/end transaction. pair. this is similarly done by zope.sqlalchemy. but it will only commit, when you tell it that the session is dirty by calling mark_changed import transaction from zope.sqlalchemy import mark_changed. here is how I use it def addKtyp(self, form, commit=1): """ create a new ktyp return id of that ktyp """ session = self.getSession() ... if values: ... if not ktyp: ... session.add(ktyp) # only mark the session, do not yet commit self.mark_changed() if commit: transaction.commit() # we only know the id after a commit !!! ktyp_id = ktyp.ktypid return ktyp_id robert
On 17.08.09 16:24, Maric Michaud wrote:
robert rottermann a écrit :
I do not see any reference to mark_changed you have to call it before any transaction.commit() to tell the zope transaction machinery that it has to commit you changes also. robert
In fact, what I understood is that zope.sqlalchemy, by default, bypasses the commit if status is not manually set as 'changed' (see the docstring I quoted in my previous mail). The alternative is to build the SessionExtension with initial_state == STATUS_INVALIDATED.
My point is that it should be the default for a DA, as it is intended to be used mainly by zsql methods which doesn't do nothing to the transaction state.
As author of SQLAlchemyDA I would assume that the transaction integration works out-of-the-box with Zope - however I have tested SQLAlchemyDA with the latest zope.sqlalchemy/SQLAlchemy versions. SQLAlchemy together with the underlying z3c.sqlalchemy/zope.sqlalchemy works with the latest Zope versions in various projects out-of-the-box using Zope 2.11. There is one project that required a special extension_options={'initial_state':STATUS_CHANGED}, parameter (used for the scoped_session(extension=ZopeTransactionExtension(**extension_options)) call). Not sure if this is related to your issue. Andreas -- ZOPYX Ltd. & Co KG \ ZOPYX & Friends Charlottenstr. 37/1 \ The experts for your Python, Zope and D-72070 Tübingen \ Plone projects www.zopyx.com, info@zopyx.com \ www.zopyx.de/friends, friends@zopyx.de ------------------------------------------------------------------------ E-Publishing, Python, Zope & Plone development, Consulting
On Mon, Aug 17, 2009 at 9:24 AM, Maric Michaud <maric@aristote.info> wrote:
robert rottermann a écrit : > I do not see any reference to mark_changed > you have to call it before any transaction.commit() to tell the zope transaction > machinery that it has to commit you changes also. > robert >
In fact, what I understood is that zope.sqlalchemy, by default, bypasses the commit if status is not manually set as 'changed' (see the docstring I quoted in my previous mail). The alternative is to build the SessionExtension with initial_state == STATUS_INVALIDATED.
My point is that it should be the default for a DA, as it is intended to be used mainly by zsql methods which doesn't do nothing to the transaction state.
Maybe I wasn't clear but the patch works well with my existing zsql code.
Andreas, We are trying out the Zope SQLAlchemy DA at work, and one of our developers saw the same problem with no commits being generated after executing zsqls (running against cx_Oracle). Can this fix be included in the upstream SQLAlchemy DA, so nobody has to monkeypatch it in? By the way, I attempted to checkout this code, to start a topic branch for this, but got a message which didn't make sense to me: svn co http://svn.zope.org/Products.SQLAlchemyDA/ svn: Repository moved permanently to '/Products.SQLAlchemyDA/'; please relocate
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brad Allen wrote:
Maybe I wasn't clear but the patch works well with my existing zsql code.
Andreas,
We are trying out the Zope SQLAlchemy DA at work, and one of our developers saw the same problem with no commits being generated after executing zsqls (running against cx_Oracle).
Can this fix be included in the upstream SQLAlchemy DA, so nobody has to monkeypatch it in?
Sorry - being to busy right now. Please commit the fix yourself and someone with Zope checkin permissions in the repos and create a new release on PyPI (just tell me the related PyPI user id). Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvRI/EACgkQCJIWIbr9KYzKaACfQ9OarTtqWa8Hc9N4uyXjCNqf VpkAmwRugE8PhxRkQKM+Px8326rrzPiR =dsfa -----END PGP SIGNATURE-----
On Thu, Apr 22, 2010 at 11:37 PM, Andreas Jung <lists@zopyx.com> wrote:
Can this fix be included in the upstream SQLAlchemy DA, so nobody has to monkeypatch it in?
Sorry - being to busy right now. Please commit the fix yourself and someone with Zope checkin permissions in the repos and create a new release on PyPI (just tell me the related PyPI user id).
Thank, I'll get started on that. Since I am not sure if that change will cause problems for anyone else using the SQLAlchemy DA, I guess I'll start it out as a development release and solicit feedback. (Regarding my earlier question about svn checkout, I had forgotten that svn+ssh was required for zope.org checkouts. It's working fine now.)
On Fri, Apr 23, 2010 at 9:44 AM, Brad Allen <bradallen137@gmail.com> wrote:
On Thu, Apr 22, 2010 at 11:37 PM, Andreas Jung <lists@zopyx.com> wrote:
Can this fix be included in the upstream SQLAlchemy DA, so nobody has to monkeypatch it in?
Sorry - being to busy right now. Please commit the fix yourself and someone with Zope checkin permissions in the repos and create a new release on PyPI (just tell me the related PyPI user id).
Thank, I'll get started on that. Since I am not sure if that change will cause problems for anyone else using the SQLAlchemy DA, I guess I'll start it out as a development release and solicit feedback.
To clarify, by development release, I am talking about providing a release which can be installed like this: easy_install SQLAlchemy==dev That would install from a development branch. The normal easy_install would still pull from the most recent release, to avoid disruption and give people time to test. After some time, it could be made to a beta release. I've had trouble finding an issue tracker for the SQLAlchemy DA. Would it make sense for me to create one on LaunchPad?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brad Allen wrote:
On Fri, Apr 23, 2010 at 9:44 AM, Brad Allen <bradallen137@gmail.com> wrote:
On Thu, Apr 22, 2010 at 11:37 PM, Andreas Jung <lists@zopyx.com> wrote:
Can this fix be included in the upstream SQLAlchemy DA, so nobody has to monkeypatch it in?
Sorry - being to busy right now. Please commit the fix yourself and someone with Zope checkin permissions in the repos and create a new release on PyPI (just tell me the related PyPI user id). Thank, I'll get started on that. Since I am not sure if that change will cause problems for anyone else using the SQLAlchemy DA, I guess I'll start it out as a development release and solicit feedback.
To clarify, by development release, I am talking about providing a release which can be installed like this:
You create a branch on svn.zope.org
easy_install SQLAlchemy==dev
Please can use mr.developer under buildout for svn checkouts. I don't want to see dev packages (in general) on PyPI.
That would install from a development branch. The normal easy_install would still pull from the most recent release, to avoid disruption and give people time to test. After some time, it could be made to a beta release.
Sorry but why do you care about easy_install? Serious people use buildout. easy_install is for playing around.
I've had trouble finding an issue tracker for the SQLAlchemy DA. Would it make sense for me to create one on LaunchPad?
There is no tracker. You don't need a tracker for such a single issue. Andreas - -- ZOPYX Limited | zopyx group Charlottenstr. 37/1 | The full-service network for Zope & Plone D-72070 Tübingen | Produce & Publish www.zopyx.com | www.produce-and-publish.com - ------------------------------------------------------------------------ E-Publishing, Python, Zope & Plone development, Consulting -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvRvXMACgkQCJIWIbr9KYzscACffqW1UH4EClktH2cJG+wkkkGD Hl8AoKrf24zd3aq+4vNaJdVAjF//RnKu =Jcgl -----END PGP SIGNATURE-----
On Fri, Apr 23, 2010 at 10:32 AM, Andreas Jung <lists@zopyx.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Brad Allen wrote:
On Fri, Apr 23, 2010 at 9:44 AM, Brad Allen <bradallen137@gmail.com> wrote:
On Thu, Apr 22, 2010 at 11:37 PM, Andreas Jung <lists@zopyx.com> wrote:
Can this fix be included in the upstream SQLAlchemy DA, so nobody has to monkeypatch it in?
Sorry - being to busy right now. Please commit the fix yourself and someone with Zope checkin permissions in the repos and create a new release on PyPI (just tell me the related PyPI user id). Thank, I'll get started on that. Since I am not sure if that change will cause problems for anyone else using the SQLAlchemy DA, I guess I'll start it out as a development release and solicit feedback.
To clarify, by development release, I am talking about providing a release which can be installed like this:
You create a branch on svn.zope.org
easy_install SQLAlchemy==dev
Please can use mr.developer under buildout for svn checkouts. I don't want to see dev packages (in general) on PyPI.
That would install from a development branch. The normal easy_install would still pull from the most recent release, to avoid disruption and give people time to test. After some time, it could be made to a beta release.
Sorry but why do you care about easy_install? Serious people use buildout. easy_install is for playing around.
Sure, we use buildout where I work. But it relies on setuptools, as does easy_install. So I was making an example of specifying an egg using easy_install, but you can also use the same version selection syntax from a buildout.cfg. To install the 'dev' version using buildout, it might look something like this: recipe = zc.recipe.egg eggs = Products.SQLAlchemyDA==dev This would allow other users to try out the dev version easily in their existing buildouts, without having to use svn recipes or mr.developer. It's important to make it low effort for people in order get more participation in testing.
I've had trouble finding an issue tracker for the SQLAlchemy DA. Would it make sense for me to create one on LaunchPad?
There is no tracker. You don't need a tracker for such a single issue.
You sound pretty confident that there won't be more issues. I'm glad, because we want to use SQLAlchemy DA in future production, and have parts of our app use zsql, while other parts call into the SQLAlchemy API, possibly from within the same transaction. I could see the possibility of more issues as we test with different database platforms like Oracle and MSSQL. Also, I am wondering if any changes in the DA will be required to support Zope 2.12+. Even if there is only one ticket to start with, it seems like a good idea to have an issue tracker. Would it make sense to use the Zope 2 issue tracker, since this is a component for Zope 2? https://bugs.launchpad.net/zope2
On Fri, Apr 23, 2010 at 11:14 AM, Brad Allen <bradallen137@gmail.com> wrote:
To install the 'dev' version using buildout, it might look something like this:
recipe = zc.recipe.egg eggs = Products.SQLAlchemyDA==dev
Or, you could put it in a version.cfg file which some buildouts use, [versions] Products.SQLAlchemyDA=dev
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Jung wrote:
Brad Allen wrote:
On Fri, Apr 23, 2010 at 9:44 AM, Brad Allen <bradallen137@gmail.com> wrote:
On Thu, Apr 22, 2010 at 11:37 PM, Andreas Jung <lists@zopyx.com> wrote:
Can this fix be included in the upstream SQLAlchemy DA, so nobody has to monkeypatch it in?
Sorry - being to busy right now. Please commit the fix yourself and someone with Zope checkin permissions in the repos and create a new release on PyPI (just tell me the related PyPI user id). Thank, I'll get started on that. Since I am not sure if that change will cause problems for anyone else using the SQLAlchemy DA, I guess I'll start it out as a development release and solicit feedback. To clarify, by development release, I am talking about providing a release which can be installed like this:
You create a branch on svn.zope.org
easy_install SQLAlchemy==dev
Please can use mr.developer under buildout for svn checkouts. I don't want to see dev packages (in general) on PyPI.
That would install from a development branch. The normal easy_install would still pull from the most recent release, to avoid disruption and give people time to test. After some time, it could be made to a beta release.
Sorry but why do you care about easy_install? Serious people use buildout. easy_install is for playing around.
That's an opinon, and one which you haven't done the work yourself to back up -- there is no buildout support here: http://svn.zope.org/Products.SQLAlchemyDA/trunk/
I've had trouble finding an issue tracker for the SQLAlchemy DA. Would it make sense for me to create one on LaunchPad?
There is no tracker. You don't need a tracker for such a single issue.
Are you claiming like Dijkstra that fixing this bug will "remove the last bug in [SQLAlchemyDA]"? +1 to adding a Launchpad project for it. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvRygsACgkQ+gerLs4ltQ5OkgCcDUIB90DqnUOqB/8VbTA2grmM x0YAoLl2KId5tTCk055OkKr2GX1t8FIX =2TWS -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tres Seaver wrote:
Andreas Jung wrote:
Brad Allen wrote:
On Fri, Apr 23, 2010 at 9:44 AM, Brad Allen <bradallen137@gmail.com> wrote:
On Thu, Apr 22, 2010 at 11:37 PM, Andreas Jung <lists@zopyx.com> wrote:
Can this fix be included in the upstream SQLAlchemy DA, so nobody has to monkeypatch it in?
Sorry - being to busy right now. Please commit the fix yourself and someone with Zope checkin permissions in the repos and create a new release on PyPI (just tell me the related PyPI user id). Thank, I'll get started on that. Since I am not sure if that change will cause problems for anyone else using the SQLAlchemy DA, I guess I'll start it out as a development release and solicit feedback. To clarify, by development release, I am talking about providing a release which can be installed like this: You create a branch on svn.zope.org easy_install SQLAlchemy==dev Please can use mr.developer under buildout for svn checkouts. I don't want to see dev packages (in general) on PyPI.
That would install from a development branch. The normal easy_install would still pull from the most recent release, to avoid disruption and give people time to test. After some time, it could be made to a beta release. Sorry but why do you care about easy_install? Serious people use buildout. easy_install is for playing around.
That's an opinon, and one which you haven't done the work yourself to back up -- there is no buildout support here:
mr.developer is your friend. Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvShfIACgkQCJIWIbr9KYxLewCffm64FP2k+P0VC4ZFznzzI5rw wEwAn1VeG7+0F1PUC06r2K6FWEWjoNES =NMhB -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Jung wrote:
Tres Seaver wrote:
Andreas Jung wrote:
Brad Allen wrote:
On Fri, Apr 23, 2010 at 9:44 AM, Brad Allen <bradallen137@gmail.com> wrote:
On Thu, Apr 22, 2010 at 11:37 PM, Andreas Jung <lists@zopyx.com> wrote:
> Can this fix be included in the upstream SQLAlchemy DA, so nobody has > to monkeypatch it in? > Sorry - being to busy right now. Please commit the fix yourself and someone with Zope checkin permissions in the repos and create a new release on PyPI (just tell me the related PyPI user id). Thank, I'll get started on that. Since I am not sure if that change will cause problems for anyone else using the SQLAlchemy DA, I guess I'll start it out as a development release and solicit feedback. To clarify, by development release, I am talking about providing a release which can be installed like this: You create a branch on svn.zope.org easy_install SQLAlchemy==dev Please can use mr.developer under buildout for svn checkouts. I don't want to see dev packages (in general) on PyPI. That would install from a development branch. The normal easy_install would still pull from the most recent release, to avoid disruption and give people time to test. After some time, it could be made to a beta release. Sorry but why do you care about easy_install? Serious people use buildout. easy_install is for playing around. That's an opinon, and one which you haven't done the work yourself to back up -- there is no buildout support here:
mr.developer is your friend.
The point is that you aren't using buildout to manage / test that package "inline": you don't have any grounds for objecting that somebody else doesn't use it either. Zope2 products can have buildouts (see GenericSetup, PAS, etc.). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvTK7oACgkQ+gerLs4ltQ5w3wCaAnv7Zdgg2vQ5IRC78QHVojAP UYAAoIzZvb6r8dKsHqBPvGkxp+MEXhJE =MvGK -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tres Seaver wrote:
Andreas Jung wrote:
Tres Seaver wrote:
Andreas Jung wrote:
Brad Allen wrote:
On Fri, Apr 23, 2010 at 9:44 AM, Brad Allen <bradallen137@gmail.com> wrote:
On Thu, Apr 22, 2010 at 11:37 PM, Andreas Jung <lists@zopyx.com> wrote: >> Can this fix be included in the upstream SQLAlchemy DA, so nobody has >> to monkeypatch it in? >> > Sorry - being to busy right now. Please commit the fix yourself and > someone with Zope checkin permissions in the repos and create a new > release on PyPI (just tell me the related PyPI user id). Thank, I'll get started on that. Since I am not sure if that change will cause problems for anyone else using the SQLAlchemy DA, I guess I'll start it out as a development release and solicit feedback. To clarify, by development release, I am talking about providing a release which can be installed like this: You create a branch on svn.zope.org easy_install SQLAlchemy==dev Please can use mr.developer under buildout for svn checkouts. I don't want to see dev packages (in general) on PyPI. That would install from a development branch. The normal easy_install would still pull from the most recent release, to avoid disruption and give people time to test. After some time, it could be made to a beta release. Sorry but why do you care about easy_install? Serious people use buildout. easy_install is for playing around. That's an opinon, and one which you haven't done the work yourself to back up -- there is no buildout support here: http://svn.zope.org/Products.SQLAlchemyDA/trunk/ mr.developer is your friend.
The point is that you aren't using buildout to manage / test that package "inline": you don't have any grounds for objecting that somebody else doesn't use it either.
I just said that I don't care about easy_install related issues. Especially because you are interested to use SQLAlchemyDA in a real-world installation as a replacement for some existing DA against a real-world database. I have never objected contributions to my software by other people. So everybody is free to fix and improve SQLAlchemyDA and other stuff on svn.zope.org - it's open source :-) Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvT6aAACgkQCJIWIbr9KYx+MQCg17r6htpZrtSfvkoS1RZbf2w9 SEQAoNJHcaBieiU8K3n0a/l1H82ZfjnC =FwX6 -----END PGP SIGNATURE-----
I've created a LaunchPad project for the Zope SQLAlchemy DA, and created a LaunchPad team of people who are interested in maintaining it. Andreas has been listed as the main driver, and links have been setup to Andrea's home page, SVN, and PyPI. https://launchpad.net/zope-sqlalchemy-da A bug for this issue has been created here: https://bugs.launchpad.net/zope-sqlalchemy-da/+bug/570208 There is a new branch commited to svn.zope which can be used to work on this fix: http://svn.zope.org/Products.SQLAlchemyDA/branches/zsql_commit_fix/ One of my co-workers, Kader has been assigned to work on this.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brad Allen wrote:
I've created a LaunchPad project for the Zope SQLAlchemy DA, and created a LaunchPad team of people who are interested in maintaining it. Andreas has been listed as the main driver, and links have been setup to Andrea's home page, SVN, and PyPI.
https://launchpad.net/zope-sqlalchemy-da
A bug for this issue has been created here:
https://bugs.launchpad.net/zope-sqlalchemy-da/+bug/570208
There is a new branch commited to svn.zope which can be used to work on this fix:
http://svn.zope.org/Products.SQLAlchemyDA/branches/zsql_commit_fix/
One of my co-workers, Kader has been assigned to work on this.
Thanks for taking this initiative, Brad! Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvV2DQACgkQ+gerLs4ltQ62SgCeJz8jd8yMe4Hl9KO8uPDwIxCx szcAoI+jysgXKdeYXhg15hdPUhE5M9oJ =37N2 -----END PGP SIGNATURE-----
Tres Seaver said:
Thanks for taking this initiative, Brad!
Thanks for the encouragement. Kader got started on this and he came up with a couple of questions: * The tests for SQLALchemy DA make use of ZopeTestCase. Is that deprecated? I found a discussion of Zope test runners in zope-dev, thread titled "circular dependency hell", which left me confused about where Zope testing is going. * The tests were written for SQLALchemy 0.4, which had a "session.save" method. SQLAlchemy 0.5 and 0.6 use "session.add". Do we need to maintain support for SQLAlchemy 0.4? I am tempted to make this new release support only 0.5 and 0.6, and see if anyone squawks. Hopefully most everyone has migrated to at least 0.5. (We can support both with conditional sqlalchemy.__version__ checks, but that can get ugly). Thanks!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brad Allen wrote:
Tres Seaver said:
Thanks for taking this initiative, Brad!
Thanks for the encouragement.
Kader got started on this and he came up with a couple of questions:
* The tests for SQLALchemy DA make use of ZopeTestCase. Is that deprecated? I found a discussion of Zope test runners in zope-dev, thread titled "circular dependency hell", which left me confused about where Zope testing is going.
Functional testing for Zope2 products likely still uses the Testing.ZopeTestCase fixtures. That discussion was largely about how to move forward the lower-level unit and integration tests for the ZTK packages (not specific to Zope2 at all), particularly to ease porthing the ZTK to Python 3.
* The tests were written for SQLALchemy 0.4, which had a "session.save" method. SQLAlchemy 0.5 and 0.6 use "session.add". Do we need to maintain support for SQLAlchemy 0.4? I am tempted to make this new release support only 0.5 and 0.6, and see if anyone squawks. Hopefully most everyone has migrated to at least 0.5. (We can support both with conditional sqlalchemy.__version__ checks, but that can get ugly).
I'm not a user, so I won't express a preference. If you do drop support for the earlier version of SA, then you need to probably bump the major versino number of the product, as well as highlighting that change prominently in the CHANGES.txt. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvXIQgACgkQ+gerLs4ltQ4kHwCgpc/F00KfGnxJU0AoA3kwIOCj C3MAn1vMxKtgdY1Ja89nvCiQ26XRFTJT =eO80 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brad Allen wrote:
* The tests were written for SQLALchemy 0.4, which had a "session.save" method. SQLAlchemy 0.5 and 0.6 use "session.add". Do we need to maintain support for SQLAlchemy 0.4? I am tempted to make this new release support only 0.5 and 0.6, and see if anyone squawks. Hopefully most everyone has migrated to at least 0.5. (We can support both with conditional sqlalchemy.__version__ checks, but that can get ugly).
Nobody cares about SA 0.4. The most current version is 0.6 and 0.5 is in maintenance mode. Keeping the dependency stack in mind: SQlAlchemy <- zope.sqlalchemy <- z3c.sqlalchemy <- SQLAlchemyDA The complete stack must fit together. Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvXIj0ACgkQCJIWIbr9KYzFNgCdEob7aNohnR9uJkNfnUDYmOb5 yK8AoJmtBurrsvuulpNZelvdoGbTVVq9 =u/tn -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brad Allen wrote:
On Thu, Apr 22, 2010 at 11:37 PM, Andreas Jung <lists@zopyx.com> wrote:
Can this fix be included in the upstream SQLAlchemy DA, so nobody has to monkeypatch it in?
Sorry - being to busy right now. Please commit the fix yourself and someone with Zope checkin permissions in the repos and create a new release on PyPI (just tell me the related PyPI user id).
Thank, I'll get started on that. Since I am not sure if that change will cause problems for anyone else using the SQLAlchemy DA, I guess I'll start it out as a development release and solicit feedback.
(Regarding my earlier question about svn checkout, I had forgotten that svn+ssh was required for zope.org checkouts. It's working fine now.)
(For the benefit of those playing along at home, maybe without commit access) I just finished documenting getting read-only checkouts over HTTP: http://docs.zope.org/developer/noncommitter-svn.html#how-to-get-a-read-only-... The tricky bit is having to add the '/repos/main' prefix to the path, in order not to land on the "browser-centric" stuff at rooted at '/'. The section above that one documents using 'svn://' URLs. http://docs.zope.org/developer/noncommitter-svn.html#how-to-get-a-read-only-... Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvRyIsACgkQ+gerLs4ltQ5LGACfX5KN8kq/6wFh5luyW485qMBl ImAAniM9fYQ5GnLkgpyDtFy2w0grsmSC =9tnu -----END PGP SIGNATURE-----
participants (5)
-
Andreas Jung -
Brad Allen -
Maric Michaud -
robert rottermann -
Tres Seaver