> > > 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. The DAL is a way of saying: "Hey, here's a bunch of objects and methods, please generate an SQL out of them, send them to the database for me and give me results" 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" Generally, as Massimo confirmed, the DAL is purely stateless. It only returns dictionary-like immediate-results. ...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?: *Multi-Tenancy, Common-Filters, Smart-Queries:* These are SQL-related features - meaning, DAL-features, not ORM ones. *Common Fields, **Automatic-Migrations, CSV/HTML/XML-Exports:* These are schema-related features - meaning, DAL/framework-features, not ORM ones * * *Labels, Comments:* These are schema-metadata-related features - meaning, DAL-features, not ORM ones. *GAE/MongoDB:* Target database-support is a low-level DAL-feature - The DAL may or may not support specific targets - but it's not an ORM feature. *JSON/List fields:* These are database-related feaatures - they are adapters for data-types that may or may not be supported in your target-database. The DAL may or may not support them, but they are not ORM features either way. *Validators, Upload/Retrieval, **Record-Versioning, Callbacks, Record-** Representations**:* These are not DAL *nor *ORM features - they are framework-features. They are input/output adapters. It is a way of saying: "Hey, when you get results back, run them through these operations". *Virtual/Computed fields:* These are kinda-tricky to classify. Computed-Fields are for automating input-transformations. They are a way of saying: "Hey, take these values that I'm *already** inserting to *these other fields, *run them through this function*, and *store the result in* that other field." Virtual-Fields are for automating output-transformations. They are a way of saying: "Hey, take these values that I'm *already **getting from* these other fields, *run them through this function*, and *produce the results as* that other field". The distinctions between these features vs. the ORM-equivalent ones, are quite subtle and illusive, but profound. The first difference is of scope - Virtual/Computed-fields can only be applied to other fields of the same Table. In (some) ORMs they are not, because an ORM class does not necessarily have to be a 1:1 representation of a table. The whole point of an ORM is to be able to construct "domain-models", not mere class-forms of Table-descriptions. In the DAL, Virtual/Computed-fields can NOT generate implicit calls to foreign-table-fields. 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.* * * As for *Lazy*-virtual-fields, they are not the sort of laziness that an ORM has - it's a deferred-execution of the automation that is defined to run on the records *after* the query has returned. In ORMs there are deferred-queries for laziness. * * *Recursive-Selects:** * The documentation on this feature is not cleat - it seems that it generates queries on your behalf, but is only useful for single-record queries, as it's like an Active-Record pattern - it doesn't do any transaction-level operation-optimizations within loops (as there are non deferred-queries). But if you use an ORM built on top of the DAL, you won't be using the DAL > API anyway, so what would you miss? Or are you saying you would still want > to use the DAL for a significant portion of code and only move to the ORM > for select parts of the application? > As many SQLA-talks explain, the use of an ORM is rarely a viable "replacement" for a DAL - it is a supplement. It's not just a matter of domain-modeling that is *not needed* or *unfit* for some use-cases - but rather a DAL should be using *within* domain-model-classes to define complex-queries. Good ORMs are not implementing an Active-Record pattern (at least not exclusively), so it should not be used as a schema-modeler only (or at all), but as a class for defining higher-level constructs with attributes derived from complex queries. > 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... :) -- --- 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.
