Hi Massimo, If dict access is overhead, we can use direct variable assignments (as mentioned in my second approach), e.g. db.cls_table (and db.cls_rows, db.cls_row, ...).
The why: I need to do lots of processing with these DAL objects (DAL, Table, Field, Set, Rows, Reference, Row, etc.) and it is much simpler, cleaner and even polymorphic to do "obj.dosomething()" (where each object responds to the same message in different ways) than "dosomething(atable)" ; it's a matter of lots of convenience as well. For reference I have tons of methods I want to attach to *all* Row instances, and (as far as I know) there's no other way than using virtual fields, which has many inconveniences (including overhead), compared to a simple instantiation of a MyRow subclass (already containing all necessary methods) ... and the same goes for all other DAL objects. These custom DAL subclasses would be defined in my models, and I believe there should be no concurrency issues, because each of these DAL instances (instantiated via the new proposed db.cls_*) exist only for the current web request (with the exact lifetime of the DAL instance) and they are completely independent across all web requests. Maybe something escapes my mind?. Thanks again!, Carlos
