I lost the meaning of your point....sorry. DAL is meant to be a "universal" glue to let the users work with some nice syntax and be able to be database independant. Used within web2py, it speeds up form creation and data retrieval for many dbs (including NoSQL ones). "YesSQL" (please bear with this term) dbs alltogether (someone more, someone less) pack the exact same "features", although hidden by some differencies in the T-SQL language, that DAL eliminates (i.e. DAL gives you the same interface for the same features in all "YesSQL" db).
Every Nosql, instead, is created/coded/implemented with very different objectives (it is what it makes them a useful tool, or they'd never gonna make it "against" the well known "YesSQL" alternatives). Those different objectives effectively "null" the possibility to have a common API to all of them while mantaining a full access to every different feature. Nonetheless, DAL abstracts "in the better way possible" the common features you'd want in a MVC application: you HAVE to have a model (even using NoSQL) if you want to expose the same data for n users and a model is required for form generation. The MVC pattern allows you to have a "common" denominator and code fast. You can still work with no model, but then DAL "loses" some of its commodities. You decided that NoSQL is the technology fit for your application. Well, DAL allows you to query a NoSQL db given that you know in advance what you want (again: your model). For the parts where a model is not known in advance, you can use the underlying NoSQL adapter of your choice to accomplish everything you want. What is your requirement then ? What are you missing ? On Saturday, August 25, 2012 7:38:03 PM UTC+2, apps in tables wrote: > > > Do you mean that this will be the next web2py example (appliance)? > --
