I love the DAL since I find it's functional programming approach very lean without the need to switch back and forth from OO to relational reasoning :-)
Moving from a mapping object (the row) to a complex custom object is much easier than it seems at the python level. ORMs on the other side tend to build objects their own style and you have to live with it. In static languages (java, C#, C++) ORM [anti]pattern actually seems a benefit. On dynamic languages like python there is no need of ORM, but there are many since it is easier and fun to develop them. Implementing *your* ORM for *your* application can be done in few lines of code, very readable and easy to maintain. The following blog entry shares much of my idea of ORM in real applications with large http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern My 4 points where I think that DAL can be (and so has to be ;-) ) improved: 1. lazy rows being backed by a sql cursor when requested by the user; 2. since point 1. is not always the solution, row object instance creation must be way faster; 3. a simple way to support db indexes even at a basic level; 4. sql view/readonly tables support (this could be related to cacheable tables). mic 2013/4/30 Massimo Di Pierro <massimo.dipie...@gmail.com> > 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<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<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. > > > -- --- 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.
