> I didn't say there were ORM features in the DAL, just that it includes >> features that you might otherwise expect to find in an ORM >> > > 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. 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. 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. 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). The ORM is a way of saying: > "Hey, here's a bunch of classes and attributes, please wire them up so > their instances would communicate their state to each other, optimizing my > transaction-operations for me as I use them" > That looks like the definition of the SQLA ORM, not ORM's in general. ...migrations, automatic file uploads/retrieval, recursive selects, >> automatic results serialization into HTML, virtual fields, computed fields, >> validators, field representations, field labels, field comments, table >> labels, list:-type fields, JSON fields, export to CSV, smart queries, >> callbacks, record versioning, common fields, multi-tenancy, common filters, >> GAE support, and MongoDB support? > > > That's a mouth-full... > Let's brake it down, shell we?: > 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. 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. > 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. > In the DAL, Virtual/Computed-fields can NOT generate implicit calls to > foreign-table-fields. > Yes, they can with recursive selects. > 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. 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). > Anyway, it may nevertheless be a useful exercise to start by using SQLA >> for some project just to see if it really delivers on the promises you >> believe it is making. >> > > Or read the documentation and some SQLA forums... :) > 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. Anthony -- --- 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.
