put them on the roadmap ^_^ as for 3. it's just a matter of finding the right syntax for every db engine. I'm not sure about 4., it's available right now with migrate=False ?
On Tuesday, April 30, 2013 12:50:04 PM UTC+2, Michele Comitini wrote: > > 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....@gmail.com <javascript:>> > >> 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+un...@googlegroups.com <javascript:>. >> 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.
