> 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. > >
That answer is too vague for me... Can you elaborate? What cascade-parameter? What do you mean by "your backend"? What "six important" event? Does this answer my questions? > > 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. > > I was referring to stateless-vs-statefull as a metaphor - an analogy. The statefullness I was trying to convey, that exist in all other frameworks except web2py, is in the ORM: SQLA assumes that the model-code is not executed for each request. It is imported once at server-launch-time. It's ORM provides a set of classes that are instantiated on-the-fly, but not in a session-lexical manner - If a request from a different session asks for a table that has an already-existing ORM-class-instance for it in memory, it will be reused. The data it contains, however, will have already been invalidated (dirty-marked) by the last database-connection-session-closing. Connection-pooling means that it re-uses connection to the database, not re-create them. A database-session-close from the point of view of the ORM, is not really a connection-close in the core-layer - it is just a release of a connection-object back to the connection pool. Then on the ORM-level, a transaction-end is not really a session-end in terms of the life-time of the class-instance-objects of the ORM classes. They persist in memory, they just get invalidated by the transaction-end. Again, it is a very different execution model from web2py - and it has nothing to do with HTTP, keep-alive, and long-lived-connections with the client - it has to do with the way the web-framework is implemented: SQLA's ORM-class-instances are reused across requests. Web2py's DAL instances are not. If I wanted to emulate a SQLA-ORM in web2py, I would have to put it all in custom-modules, that would persist class-instances in memory, and do a lot of these invalidation/dirty-chacking stuff myself. I think a way around this might be to keep the DAL-layer separate, in that instances of ORM-classes may persist in memory across requests in a custom module that is not reloaded, but that they would be dynamically re-linked to DAL instances that would still be re-generated for each request by executing the models as usual. This is what I mean by another layer on-top of the DAL. How to implement such a thing? This is way over my league... > > 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. > > In respect to my previous section, the auto-generation of query-objects, should be done "within" the ORM layer, that just "uses" the DAL instances. The reason for this is that behavioral-characteristics for domain-model classes, go in the ORM layer - that's what it's for. > > 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. > The DAL is an abstraction-layer. It's purpose is that you should not need to go beneath that layer, unless things go horribly wrong. This means, that for 99% of the usage, you shouldn't care what goes on underneath in the low-level SQL. Otherwise, there really is no need for a DAL at all... The same would go for an ORM layer. It should help you facilitate the mapping of your business-logic classes to database-classes, and define automation of database-layer-behavioral-patterns, as a function of business-logic behaviors, "within" you your business-logic layer, and not the database-layer. This is in a nutshell what I am after, and where I think an ORM layer on-top of the DAL could be most beneficial. > 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 ? > > I'm not sure I understand what you are saying here, but it seems to pertain to my last comment in the previous section. -- --- 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.
