Thanks for the detailed response.
I have two follow-up questions:
1) From what I understand, if I read an "object" (eg, Student) from
the database, modify that object or other objects, and then commit, I
have no guarantee that the object didn't change between the time I
read it and the time I committed. For example:
if len(Session.query(Student).filter_by(Student.name ==
'Bill').all()) > 0: # are there any students named 'Bill'?
school = Session.query(School).one() # assume there is one
school in the database
school.hasStudentNamedBill = True
Session.commit()
When the commit is issued, I might end up with an inconsistent
database, because a different transaction (in another thread, for
example) may have changed the name of the student after I checked if
there is a student named Bill, but before I committed. From the last
answer it seems like databases that support transactions might not
suffer from this problem (if they take locks on SELECTed rows), but I
tried in SQLite (which supports transactions) and it didn't help.
Would a different database help solve the problem?
2) You mentioned that the recommended approach to roll back in SA 0.4
is to call rollback() and then clear(). Can I just call close() on the
session instead? From the documentation it seems that close() is
essentially a rollback combined with a clear.
Thanks!
On Jun 7, 9:29 pm, Michael Bayer <[EMAIL PROTECTED]> wrote:
> On Jun 7, 2008, at 3:50 PM, Tomer wrote:
>
>
>
> > Thanks. What would happen if I didn't do anything (I've seen lots of
> > examples online that will just issue a query like
> > Session.query(User).all() and that's all). Will that query start a
> > transaction if it's a transactional session?
>
> when you use the DBAPI (which every SQLA driver does), anytime you get
> a hold of a connection, there is a transaction in progress. Depending
> on what database backend you're using, this might have different
> meaning; such as if you're using MySQL with ISAM tables, there isnt
> really much transactional. But generally, selecting from tables
> implies that those rows might be pulled into the transaction such that
> changes made external to the trans aren't visible (depending on
> isolation behavior). But this doesn't actually "write" anything to
> the database. Only INSERT/UPDATE/DELETE has that effect. When using
> the ORM, these operations are encapsulated entirely wihtin a flush(),
> so if your transaction does not flush(), then nothing is written.
>
> Doing a rollback() will ensure completely that nothing is written,
> even if flushes have taken place. With SQLA 0.4, rollback() has the
> caveat that the Session is not really usable after a rollback() until
> it is clear()'ed. With 0.5 this restriction is lifted.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
