This is nice, but you're still talking about very general features. It would be more helpful if you could explain why we need those features. Perhaps you could show in SQLA how you would specify and interact with a particular data model, and then explain why you think that is better/easier than how you would do it using the DAL.
Anthony On Monday, April 29, 2013 9:17:44 PM UTC-4, 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 web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
