I think you're arguing against a bit of a straw man here. Past resistance to the idea of an ORM has usually been in the context of suggestions for an ORM *instead of* a DAL, not as an additional abstraction on top of the DAL for particular use cases. As Massimo noted, there have already been some efforts at the latter, though none generated enough interest to persist. If you can identify a common use case where some kind of abstraction on top of the DAL would make development much easier and/or execution more efficient, and you can clearly articulate the nature of that abstraction, I don't think anyone would object. It might help to see something concrete, though. Let's see an example data model, how it would be easily implemented in SQA or the hypothetical web2py ORM, and how that is a clear improvement over how you would otherwise have to implement it using the DAL. I also wonder if it is a full-blown ORM that is needed, or just some additional DAL functionality to more easily accommodate particular types of data models.
Anthony On Sunday, April 28, 2013 2:41:46 PM UTC-4, 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 this 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-directionally from the schema, and > supply event-listeners for each end of each multi-targetted 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 expirations, 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 db-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.
