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 web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
