On Sunday, April 28, 2013 8:41:46 PM UTC+2, Arnon Marcus wrote: > > > And where did you see a lack in functionality using DAL callbacks ? >> >> > > I am not that familiar with them, honestly. > As I said - It may seem as though I am saying that web2py currently > can-not accomplish this - what htis actually means, is that "I don't know > of ways in which web2py can accomplish this" > I would be more than happy to find out that I am wrong! :) > > How can DAL-callbacks be used to emulate this? > Can they auto-infer relationships bi-direction ally from the schema, and > supply event-listeners for each end of a each multi-target relationship? > How would I factor such a mechanism into my own classes to link them up? >
they don't build up magically by default (though the cascade parameter allows the same flexibility as the one present in your backend) but given that all the six "important" events are available and fired accordingly, you can hook up whatever business logic you like. > > 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. >> > > I said that most of our code is in custom-modules, so obviously I know > that web2py "supports" this. > > What I meant by that, is that it seems as though due to the fact that > web2py "executes" the models, and so has implicit-session-management going > on on the DAL, it "assumes" a "data-model-session" by default. So, the > characteristics and features of the DAL are (obviously) targeted > at supporting this mechanism. All other frameworks do not execute the > models on each request. You may write a reload(), but that's your business > So, SQLA is designed to support this execution model, which is why it has > to provide all these wild connection-sessions, transactions, and > table-cache-invalidation mechanisms with expiration, dirty-checkings and > the like... > > Web2py took advantage of it's execution to basically allow itself to > completely avoid any of these stuff. > So, if you want to implement a data-model using the DAL "within a > non-executed/non-reloaded custom-module", than you are basically on your > own for implementing all these crazy bb-sessions and the like. > > > This is why it seems so odd for web2py users to grasp this notion of an > ORM, as it is basically assuming a totally-different execution model for > the db-models, compared to how it is currently built in web2py. > > It is like the different between a statefull system, and a stateless one. > SQLA is built for statefull applications. > Web2py's DAL is built for stateless ones. > It's a very different paradigm, with a different way of thinking. > And because of that, it is so wired to try to think about an ORM in > web2py, especially if it is going to sit in a "statefull module". > > Perhaps I am missing something here, but this is how I > currently understand things. > > HTTP is (ATM) a stateless world. Yep, cookies are used to store something from different requests, but that's business logic of your app, not a database concern. Even with SQLA you DON'T want to "keep alive" a session between multiple requests, as you can very easily end up in lockings. > 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. >> > > Obviously, but that's not the point - we are talking about "tools for > automating abstractions". He did not write the join himself there... > The eager-loading system figured out by itself which joins it should > construct in order to eager-load things - all he did is tell the system to > do so for that relationship. > And what's different than looping over all the referenced tables and joining them ? Do you really need a 10-lines code snippet to accomplish that in DAL ? This can go in the "please add features to DAL" chapter, as other things mentioned before, but don't really count for an ORM. > >> 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. >> > > No. It's as if you completely missed his point. SQLA's ORM philosophy is > different than others. Did you watch the lecture I gave you about that? > SQLA is not building your models - you are. > SQLA is not "hiding", it is "automating". > SQLA is not "obtuse", it is "transparent". > SQLA does not lock you into it's defaults - you define it's defaults > up-front. > That means exactly what I meant to explain before: you define how it should work beforehand and you need to review the model to understand what is "firing" under the hood. > >> 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. >> > > No. It's automatic. You set-up the "relationship" object yourself - yes - > but IT figures out whether this is a one-to-many relationship, and to which > direction, and constructs an optimized query based on which end of the > relationship you are querying. As he said, this is non-trivial in ORMs - > Django's ORM (as he alluded...) is NOT doing that... > So, you added a lot of statements and pieces of code in your model to define the relationship, and SQLA replays it figuring out "the most optimized way possible". My point of "I end up with a nice schema to play with" may be throwing me ahead of road-blocks that you faced, but is it really that difficult to code a relationship and figuring out how to query it ? -- --- 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.
