Well, it seems like a semantic-issue. DAL and ORM are pretty abstract-terms. >> Here is how interpret them: >> DAL - A way to construct schemas and queries without writing SQL or DBAPI >> calls. >> ORM - A way to construct domain-models using a DAL in a statefull manner. >> > > I don't think you are understanding me, so let me try to be more clear. > Let's say an ORM is a particular design pattern for modeling data, and a > DAL is a different design pattern for modeling data. Each of those > different design patterns can nevertheless be used to implement similar > types of features. For example, you might want to query the database and > return a results set. This can be done in an ORM, and it can be done in a > DAL. The implementation and the syntax will be different in each case, but > they are both implementing a common feature. So, when I say the DAL > implements features that might otherwise be found in a typical ORM, I am > not saying the DAL implements an ORM design pattern, just that it > replicates functionality for which you might otherwise use an ORM. >
No, it does not do that. It implements very different functionality, that may have a similar API and the same terminology used, which honestly I find quite confusing - border-line misleading. I have given a very specific and granular description of the differences of such functionalists between an ORM and web2py. > For example, in an ORM, you can define a method in a class that returns a > value calculated from the fields of a database record. In the web2py DAL, > this same functionality can be achieved using a virtual field or lazy field. > There are no lazy-fields in web2py, and I find the terminology misleading - as I said - *lazyness *in the context of *database-access*, is a * deferred-query* - NOT a *deferred-calculation* of the *results *of a query. The difference is to profound to overlook. Deferred calculations of field-results are generally useless - web-applications are generally I/O-Bound much more than CPU-Bound - so the benefits of deferring is mute in post-query calculations compared to benefits in deferred-queries that are used within the context of transaction-operation-optimizations - which is the context most people would thing of whenever they here the term *Lazy* thrown about a database-context, > I don't know if the SQLA CORE has virtual fields, but if it doesn't, I > would suppose it leaves this kind of functionality to the ORM. > That's irellevant to the comparison of SQLA-Core vs. web2py-DAL, since I am not suggesting using the SQLA-Core and dumping it's ORM - quite the opposite - and since virtual-fields are actually much more beneficial when used within an ORM layer, as opposed to a DAL one. The only relevance for this point to this discussion, is the comparison of the sized of the code-bases. I get that this was what you meant. > That looks like the definition of the SQLA ORM, not ORM's in general. > Not quite - look ar my comment to Derek down below. > > No, let's not. My point is not that any of those items properly belong to > either a DAL or an ORM, or that they can only be implemented with either a > DAL or an ORM design pattern. Rather, you had claimed that the SQLA CORE is > equivalent to the web2py DAL and that all 20,000+ lines of SQLA ORM code > must therefore be providing unique functionality not available in the DAL > (thus implying that the ORM must be useful). I was just suggesting that the > DAL might be doing more than the SQLA CORE (at least in some areas), and > that the DAL might possibly be offering some features for which you would > otherwise need the SQLA ORM. > > You are saying that a lot of web2py's extra-features that extend on-top of the DAL, might not be included in SQLA's Core, but rather may represent a big portion of the 20K lines of code of the ORM, which would then suggest that the features I was excited about may actually represent a much minor portion of the 20K code-base, which would then suggest that they may be small, and therefore legitimate for being considered "useless". You could have said so more clearly (like I just did) and prevent the confusion. Now, if you would have seen the lecture I gave Massimo the link to watch, you would have seen how complex these features might be, so I doubt they are implemented within a small code-base. But if they do, this would degrade your argument that this is such a "substantial-investment" as you called it... But In either case, I would go for trying to use what they wrote, long before I would consider re-inventing it... > The point is, many features found in DAL's and ORM's are not unique or > specific to the DAL or ORM design pattern. Each design pattern can be used > to implement many common types of functionality (the functionality may not > be identical, but at least similar, and used to satisfy the same goals). Regarding all the features you claim are inherently DAL features and not > ORM features, I disagree. Any one of those features could rightly be part > of either a DAL or an ORM. They are simply features you might want to > implement within any data modeling abstraction, whatever the design pattern. > What I meant, was that the "essence" of an ORM, is NOT these features. Any kind of Access-Layer-API may contain some of these features, yes - I agree - but that was not the point - the point was that the MAIN role an ORM has, is not found in these features - it is in the mapping of relations to domain-model objects - which is not what they are all about (again, check-out my comment to Derek below). So you may say they are not DAL-related, but in that case they would be just as unrelated to an ORM as well. API-implementations may vary, as to what auxilary-features are present for convenience, but I found it misleading to allude that by the mear inclusions of such features in web2py, that it somehow get's it closer to providing ORM functionality - this is not the case - as ORM-functionality - at it's core - is the design-pattern of providing domain-model tools - not the existence of convinience-auxiliary features. > The first difference is of scope - Virtual/Computed-fields can only be >> applied to other fields of the same Table. >> > > No, they can also be applied to the results of joins (not sure if that's > typically as easy to do in an ORM) -- see > http://web2py.com/books/default/chapter/29/06#Old-style-virtual-fields. > > I have read this whole DAL section in the book today - I know you can super-impose virtual-fields onto row-objects that result from a JOIN operation - but that's such an edge-case with such marginal-utility, that it can hardly even be considered a "feature"... I was comparing that to the fact that ORM classes may contain representations of fields from multiple-tables from the get-go - so it can be used for "querying" multiple-tables - NOT for result-manipulations of JOINs (Which has questionable-utility at best) > In the DAL, Virtual/Computed-fields can NOT generate implicit calls to >> foreign-table-fields. >> > > Yes, they can with recursive selects. > I touched on Recursive-selects further along, they are useless for 2 reasons: 1. They are Active-Record-like implementations - using it on a field within a for-loop is a big no-no for DAL usage, as there it would generate tons of queries. In an ORM, because it is statefull, you could do an eager-load for the foreign-table in order to cache it - THEN it would be usefull, as the foreign-table-access would not generate tons of queries. 2. It is only applicable for single-relational fields - which are few and far between in real-life code - for more complex relationship, the backward-relational-inference brakes down. SQLA solves this with the "relationship" object - basically defining relationships on both ends, so that the ORM object-graph contains a bi-directional reference (the creator had to talk to Guido to find-our how to do that, so it would not create a cyclical-object-reference that might become a memory-leak, but eventually they got it working). So again, it seems that web2py has features with syntax that makes it "appear as though" it has ORM-usefull stuff there, when in fact it doesn't. Again, misleading... > The second difference is of statelessness-vs-statfullness - The DAL is >> stateless, so it can-not give values from a previous query. >> ORMs are statefull in nature, so: >> - For output, Virtual-fields can use *values **already stored* in those * >> other-field's* cache, and *not even query* the database. >> - For input, Computed-Fields can use* values **already stored* in those * >> other-field's* cache, and *not even insert* them to the database. >> The DAL is stateless in nature, so: >> - For output, Virtual-fields *must* *query **values* from those * >> other-field*, in order to invoke the functionality of the >> automated-output. >> - For input, Computed-Fields *must insert values* to those *other fields, >> * in order to invoke the functionality of the automated-input. >> ** There is also cache for the DAL, but it's time-based, and not >> transaction-based.* >> > > I'm not quite sure what you mean here. Even in an ORM, in order to > calculate the value of a virtual field, you first have to retrieve the > input field values from the database; and when creating a computed field, > you still ultimately have to write the computed value to the database. > No. ORMs are statefull - It you have already data loaded from a oreviouse query in those source-fields, than a virtual-field would not have to round-trip to the database at all - it would just use the cached-values in the source-fields. As for computed-fields, again, the benefit is for storing a computed-value, so it will not have to be re-calculated. So yes, "eventually" the computed-value would be saved to the database, but it doesn't have to occur in the calculation-operation - it can just leave the calculated-value in memory, for further use in subsequent queries within the same transaction. Additionally, similarly-to-virtual fields, here again the source-fields for the calculation, may already exist in memory from previouse queries - so the calculation would not requier a round-trip to the database. > > Also, be careful not to confuse ORM's in general with the SQLA ORM in > particular -- some properties you claim for ORM's are unique to SQLA, and > they are not necessarily properties that can be implemented only within the > ORM design pattern (i.e., they are not limited to ORM's). > No - they are not limited to ORMs - but they ARE limited to statefull-frameworks, which most web-frameworks are and web2py is not. Transitional-scope-persistence may be implemented in a DAL in a statefull web-framework (which again, web2py isn't) - but the utility would still be limited when compared to having that within an ORM domain-class object-graph. That said, you are right about one thing - if the DAL would get statefulness, many of these features would become immensely more beneficial - almost automatically. It is a matter of statefullness - not or design-pattern of domain-classes. But still, a statefull-domain-class implementation, would still benefit more out of such features than a web2py's DAL, ans so would still be superior. > > Which I'm assuming you have not yet done, as you have yet to show an > example of something you can do easily in the SQLA ORM but find difficult > or inefficient in the DAL. A real project might help to surface some > compelling use cases and provide benchmarks for possible efficiency gains. > I think in this very comment, and the one before, as well as my response to Derek about ORMs, as well as in many lectures I've posted here, there are more than sufficient reasons to see benefits of using SQLA's ORM as opposed to web2py's DAL. It is an architectural-issue, not a use-case one. Given all I've alrady written, insisting on requesting for actual use-cases, when the architectural-issues are obviously already so glaring - it would seem like a picky - borderline straw-men - argument. web2py is stateless - by design - it was a conscious design-choice, weighing the pros/cons and trade-offs - and at the end adding all these ORM-like features just seems like a futile attempt at rounding the square (or squaring the circle - whichever you like). -- --- 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.
