You don't get to define terms any way you see fit. DAL and ORM have specific meanings.
DAL is a TLA (three letter acronym) for "Database Abstraction Layer". ORM is a TLA for "Object Relational Mapping". So, what does a DAL do? Wikipedia tells us that it "... is an application programming interface<http://en.wikipedia.org/wiki/Application_programming_interface> which unifies the communication between a computer application and databases<http://en.wikipedia.org/wiki/Database> such as SQL Server <http://en.wikipedia.org/wiki/MSSQL>, DB2<http://en.wikipedia.org/wiki/IBM_DB2> , MySQL <http://en.wikipedia.org/wiki/MySQL>, PostgreSQL<http://en.wikipedia.org/wiki/PostgreSQL> , Oracle <http://en.wikipedia.org/wiki/Oracle_database> or SQLite<http://en.wikipedia.org/wiki/SQLite>. Traditionally, all database vendors provide their own interface tailored to their products which leaves it to the application programmer to implement code for all database interfaces he or she would like to support. Database abstraction layers reduce the amount of work by providing a consistent API to the developer and hide the database specifics behind this interface as much as possible. There exist many abstraction layers with different interfaces in numerous programming languages." What does an ORM do? Wikipedia tells us that it "... is a programming<http://en.wikipedia.org/wiki/Computer_programming> technique for converting data between incompatible type systems<http://en.wikipedia.org/wiki/Type_system> in object-oriented <http://en.wikipedia.org/wiki/Object-oriented> programming languages. This creates, in effect, a "virtualobject database<http://en.wikipedia.org/wiki/Object_database>" that can be used from within the programming language. " So, the two terms are not mutually exclusive, but they handle different domains. It may be interesting to have an ORM on top of DAL, but I personally feel that creating YAORM (Yet Another Object Relational Mapping) is counter-productive especially when you could bypass the DAL and just use SQLA which you yourself say is the best ORM there is. Now, perhaps what may be beneficial is to separate the DAL from the HTML generation and data validation logic. That way, you could plug in SQLA and yet your SMARTGRID and FORMs would work with all the bells and whistles. On Wednesday, May 1, 2013 7:15:11 AM UTC-7, Arnon Marcus wrote: > > >> 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
