> 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? 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. 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. > 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. > > 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... -- --- 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.
