2013/4/30 Niphlod <niph...@gmail.com> > 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 ?
4. migrate False is on the DDL side and you are right about that, but I'd like it also on DML part i.e. in postgresql doing an INSERT on a VIEW is not allowed. > > 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<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> >> >>> 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/**fil**es/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/**fil**es/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-**acc**ess >>>> - 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. >>> >>> For more options, visit >>> https://groups.google.com/**groups/opt_out<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. > > > -- --- 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.
