could zope.sqlalchemy flush before committing?
I complained recently about problems with things disappearing from an in-memory sqlite database. It appears that my problems were actually symptoms of something else: that, so far as I can see, doing a transaction.commit() when SQLAlchemy is active does *not* first do a session().commit()! This means that the following sequence in a test suite:
p = Person(name='Brandon') s = session() s.add(p) transaction.commit()
s.attribute = 'an illegal value' Traceback: ... Exception: the database does not allow that attribute to have that value transaction.rollback()
Instead, to make this work, one has to write the first stanza as:
p = Person(name='Brandon') s = session() s.add(p) s.flush() # Sheesh transaction.commit()
Could zope.sqlalchemy be improved so that, on transaction commit, the current SQLAlchemy session is first flushed before being committed? -- Brandon Craig Rhodes brandon@rhodesmill.org http://rhodesmill.org/brandon
Brandon Craig Rhodes <brandon@rhodesmill.org> writes:
I complained recently about problems with things disappearing from an in-memory sqlite database. It appears that my problems were actually symptoms of something else: that, so far as I can see, doing a
transaction.commit()
when SQLAlchemy is active does *not* first do a session().commit()!
Drat. I meant, as I hope the code examples that followed made clear, that doing a "transaction.commit()" does not do a session().flush(). -- Brandon Craig Rhodes brandon@rhodesmill.org http://rhodesmill.org/brandon
This is now fixed in trunk. For the moment I'm depending on SQLAlchemy trunk for the new after_attach hook until beta3 is released. Maybe it's time to start depending on 0.5? Laurence Brandon Craig Rhodes wrote:
I complained recently about problems with things disappearing from an in-memory sqlite database. It appears that my problems were actually symptoms of something else: that, so far as I can see, doing a
transaction.commit()
when SQLAlchemy is active does *not* first do a session().commit()! This means that the following sequence in a test suite:
p = Person(name='Brandon') s = session() s.add(p) transaction.commit()
s.attribute = 'an illegal value' Traceback: ... Exception: the database does not allow that attribute to have that value transaction.rollback()
Instead, to make this work, one has to write the first stanza as:
p = Person(name='Brandon') s = session() s.add(p) s.flush() # Sheesh transaction.commit()
Could zope.sqlalchemy be improved so that, on transaction commit, the current SQLAlchemy session is first flushed before being committed?
Laurence Rowe wrote:
This is now fixed in trunk. For the moment I'm depending on SQLAlchemy trunk for the new after_attach hook until beta3 is released.
Maybe it's time to start depending on 0.5?
No problem with that from my side, though of course I think this means beta3 should be released first, right? Regards, Martijn
On Jul 19, 2008, at 6:33 AM, Martijn Faassen wrote:
Laurence Rowe wrote:
This is now fixed in trunk. For the moment I'm depending on SQLAlchemy trunk for the new after_attach hook until beta3 is released. Maybe it's time to start depending on 0.5?
No problem with that from my side, though of course I think this means beta3 should be released first, right?
The 0.4 series can handle an after_attach() hook just as easily as 0.5...would this make life easier ?
Hi there, Thanks for the offer. I think this is up to Laurence to decide, I'd say. I'm aiming my work at the 0.5 series so I'm fine with requiring 0.5. Regards, Martijn
Martijn Faassen wrote:
Thanks for the offer. I think this is up to Laurence to decide, I'd say. I'm aiming my work at the 0.5 series so I'm fine with requiring 0.5.
Me too, but I'd be careful to *require* an unreleased version. \malthe
Hey, On Mon, Jul 21, 2008 at 9:55 AM, Malthe Borch <mborch@gmail.com> wrote:
Martijn Faassen wrote:
Thanks for the offer. I think this is up to Laurence to decide, I'd say. I'm aiming my work at the 0.5 series so I'm fine with requiring 0.5.
Me too, but I'd be careful to *require* an unreleased version.
Well, I was assuming there'd be a (beta) release at least. z3c.saconfig has been requiring a released beta version of 0.5. Regards, Martijn
i should be doing 0.4.7 and 0.5beta3 early this week. both include "after_attach()". On Jul 21, 2008, at 4:45 AM, Martijn Faassen wrote:
Hey,
On Mon, Jul 21, 2008 at 9:55 AM, Malthe Borch <mborch@gmail.com> wrote:
Martijn Faassen wrote:
Thanks for the offer. I think this is up to Laurence to decide, I'd say. I'm aiming my work at the 0.5 series so I'm fine with requiring 0.5.
Me too, but I'd be careful to *require* an unreleased version.
Well, I was assuming there'd be a (beta) release at least. z3c.saconfig has been requiring a released beta version of 0.5.
Regards,
Martijn
Laurence Rowe <l@lrowe.co.uk> writes:
This is now fixed in trunk. For the moment I'm depending on SQLAlchemy trunk for the new after_attach hook until beta3 is released.
Could the fix be backported and a new release made? I have to have this particular system ready for production next week, and would love to not have to explain why it was running out of Subversion in production. :-) -- Brandon Craig Rhodes brandon@rhodesmill.org http://rhodesmill.org/brandon
On Jul 19, 2008, at 10:29 AM, Brandon Craig Rhodes wrote:
Laurence Rowe <l@lrowe.co.uk> writes:
This is now fixed in trunk. For the moment I'm depending on SQLAlchemy trunk for the new after_attach hook until beta3 is released.
Could the fix be backported and a new release made? I have to have this particular system ready for production next week, and would love to not have to explain why it was running out of Subversion in production. :-)
backported to ... 0.4 ? sure.
Michael Bayer wrote:
On Jul 19, 2008, at 10:29 AM, Brandon Craig Rhodes wrote:
Laurence Rowe <l@lrowe.co.uk> writes:
This is now fixed in trunk. For the moment I'm depending on SQLAlchemy trunk for the new after_attach hook until beta3 is released.
Could the fix be backported and a new release made? I have to have this particular system ready for production next week, and would love to not have to explain why it was running out of Subversion in production. :-)
backported to ... 0.4 ? sure.
Yes please. Sounds like this would be helpful to people. Laurence
participants (5)
-
Brandon Craig Rhodes -
Laurence Rowe -
Malthe Borch -
Martijn Faassen -
Michael Bayer