Whoa, that's definitely a lot to digest, but frankly..... again with no practical usecases to digest too ^_^...
>From the "technical" standpoint I love (being more a sql guy than a python one) to avoid defining a class when what I know that what I want is a table. That's more or less the (well specified) difference between an "expression layer" and an "object mapper". That comes probably because I know already how to design the tables beforehand, having planned the requirements. Elaborating on this, I see a lot of users that are probably "less expert" on the db side that entangle themselves on a really hard "model mapping" and have, in my POV, crazy "query requirements" to fetch some rowset they need. I hardly fall into that situation, so I guess my understanding and "expertise" help me plan beforehand a good "environment" to play with DAL. That being said, doing a db.define_table() and a class Whatever(model) isn't that much different in terms of what you gain access to..... db.table has 'fields', every field has its sets of attribute (default, requires, update, type, etc etc etc). For references, you know already that every single column of a row holds a pointer to the referenced row.... As for "mixins", web2py has table inheritance .... I guess all that comes up in term of differences is merely technicalities.... as far as my projects went, I rarely had the need to define "real python classes" to interact with "my mind model".... Doing Record.find(1) is not that different from db.record(1) as far as I'm concerned, and I have a lot more control on what an hypotetical Record.save() does with record.update_record() as far as db queries are concerned (ok, I know that an "expression layer", having a "layer less", helps retaining control on what is happening between your models and your db, but that's why I like it :-) ) . >From the moment callbacks were put in trunk (and I will be thankful until I die for those :-P) I couldn't find anything that can be done with an ORM that is not easily replicable with DAL. >From DAL to SQLA there are of course many differences, but DAL tries to expose the 95% of the features with an homogeneous API. SQLA is more "flexible" but every adapter has its set of features that closely builds on the backend available features. The only thing I miss from SQLA is the wonderful "session". I guess in your post is described in the lines It should also facilitate performance-optimizations, by way of a > transactionally-aggregating queries and updates/inserts automatically. > but dude, believe me, it's very, very, very hard to support "python-side" nested transactions, each one with their own commit/rollback. That's why you find that bit of functionality in 2 libraries in the whole python world: SQLA and Django's ORM (to be fair, Django's one covers a lot less of cases) What do you miss, specifically, from the DAL standpoint ? -- --- 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.
