Another past effort: https://code.google.com/p/web2pyorm/
On Sunday, April 28, 2013 8:59:40 PM UTC-4, Anthony wrote: > > 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
