Why not write a driver for SQLA that speaks DAL instead of a sql dialect?
2013/5/1 Derek <sp1d...@gmail.com> > 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 web2py+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- --- 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.
