On Sunday, April 28, 2013 1:00:17 AM UTC+2, Arnon Marcus wrote: > > > even with an ORM your code wouldn't be as neat as you might think. > > > Well, SQLA has this cool feature called "relationships", which basically > lets you define bidirectional relationships between ORM classes. After > you define it, there are events that will take care of updating the > relationships for added/removes records for all direction in all > relationships defined: > > http://www.youtube.com/watch?feature=player_detailpage&v=woKYyhLCcnU#t=7962s > * * Time-coded link : watch about 7 minutes...* > p.s: This can also facilitate the build-up and maintenance of > tree-structures. >
And where did you see a lack in functionality using DAL callbacks ? > > But I think the main issue here is different, though - it may have to do > with web2py's execution-model - having it "execute" everything for each > request - so there is nothing being saved across-requests... > However, "modules" are not automatically-reloaded, and it is actually in > THIS place where I would expect to put my ORM... This is in fact the main > issue that is not considered in web2py... > > Just because the scaffolding app doesn't have any module in it? I use modules all the times if I don't want to reload the code at every request, that's why they are available. > > If instead you're talking about DAL "optimizing" whatever you do to the >> minimum required number of queries.. > > > Hmmm, well, then what would you call SQLA's "eager-loading", then? > > http://www.youtube.com/watch?feature=player_detailpage&v=woKYyhLCcnU#t=9445s > * * Time-coded link - watch about 10-15 minutes from that point* > * > * > That's just avoiding recursive queries. Again, SQLA doesn't figure out it for you, you have to instruct it to be "eager" upfront. At that point, you can instruct DAL to be eager too with joins. > ** > > ORMs on the other hand are a little bit more "obscure" in terms of "what >> will happen when I choose to alter this object". > > > Are they? Really?: > > http://www.youtube.com/watch?feature=player_detailpage&v=woKYyhLCcnU#t=8214s > * * Time-coded link : watch about 2 minutes* > > Yep, really. Whenever I use db(query).select(), .update(), .delete() I know that a query is fired (sort of "explicit is better than implicit"). If I use SQLA I have to remember how the particular model was coded (and optionally do some debugging) to see what's going on under the hood. Please note that this is expected: you want an ORM to have another layer of abstraction on top of database operation, so by default is more implicit. > > ORMs can do that kind of "optimization" (up to a certain point) but please >> note that you're asking the code to be smarter than you. >> > > How about SQLA's lazy-loading? > http://www.youtube.com/watch?feature=player_detailpage&v=woKYyhLCcnU > * * Time-coded link :watch 1 minute* > Same thing as before. You have to tell it upfront, and it's not different from planning what to do with one/two/n DAL queries. -- --- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
