Hello Arnon, In web2py all DAL operations are wrapped in a transaction which can be committed explicitly via db.commit() or automatically at the end of an http request. It does not suffer from the problems of Active Records mentioned in the slides where each object is committed separately and thus things can get out of sync.
In web2py objects are not proxies, as they are in SQLA. The DAL is simply an abstraction to generate SQL for you. the DAL api (insert/delete/update/select) are mapped into the corresponding SQL statements and executed when called, not deferred. Transactions are handled at the database level. This has pros and cons. The pro is that the developer knows when the DB IO is performed. In the SQLA ORM because objects are proxies and DB IO is always lazy, you do not know when DB IO is performed. I do not like that. Yes this is cool from an implementation point of view but still I need to understand what benefit it provides. It does not seem to provide a performance benefit. It does provide a consistency benefit but the consistency problem only exist if the object persists beyond the session in which it is defined. In DAL records are not objects, they are dictionaries, and they only exist for the life of an HTTP request therefore it is not clear one gains anything from the extra complexity. In other words, in my view, the consistency problem is a database problem. ACID and Transactions solve it. Some ORM move the problem at the application level because of the imperfect map between SQL API and Object API. This creates a problem and they have to jump hoops to solve it. Sessions partially solve the problem the ORM created. Perhaps I am missing something. Massimo On Monday, 29 April 2013 20:17:44 UTC-5, Arnon Marcus wrote: > > So, clean-slake here - who is excited about SQLA's unit-of-work/session > implementation? > > http://youtu.be/uAtaKr5HOdA<http://pyvideo.org/video/1767/the-sqlalchemy-session-in-depth-0> > > * The slides for it are here: > http://techspot.zzzeek.org/files/2012/session.key.pdf > > * Thw second-half shows an interactive walk-though of it, using HTM5, > which > you can manually interact with yourself using this: > http://techspot.zzzeek.org/files/2012/session.html.tar.gz > > How much of that is the DAL doing? How does it map to it? > Would it be correct to say that a db-connection is akin to an > SQLA-session? > > I have gone through the DAL documentation again, and I've seen glimpses of > parts of this, but the whole auto-querying-on-attribute-access - with > implicit-transaction-caching - is a really cool feature. > Can I do "db.person[1].name" and have it query the database "if and only > if" this value was not already queried in the current transaction? > > I saw that it "auto-commits" at the end of each request/response session, > right? > So, this is the DB-transaction view that is "committed", right? > So, if I manually-commit - it automatically starts a new transaction? > If I get a row object, then run the same query again - will I get the same > row-object internally? I mean, does the DAL do this cool identity-map thing > internally? > > I'm thinking about this whole dirty-checking/invalidation thing - it seems > crucial for enabling orm-like access to the records (meaning, > auto-query-on-access). > > We could emulate that in an abstraction-layer - I think this is what I am > after. > Am I being more clear now? > With these features in the DAL, I we can pass-around the db object from > controller-actions to custom-modules, instantiating it's classes with it - > which would be the equivalent of passing the "session" object in SQLA. > > This way, we can build classes that provide attribute-accessors that proxy > DAL-SET-objects, and include implicit-cashing with a memoizer, and even go > farther and do lazy-loaders with deferred-query classes. > > What do you say? > -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
