>> I think this would be a great feature to have because there are >> many use >> cases in my application (mainly displaying/processing tables) where I >> don't want/need the overhead of the instrumentation (and it really >> does >> add quite a bit), but would still love the excellent mapping abilities >> (i.e have fully hydrated domain objects rather then ResultProxy). >> > > I think theres still going to be a lot of overhead even without > instrumentation. anyway, this would be an enormous amount of effort > to establish and also to keep test coverage going, and would probably > be a significant complication to the internals. Id rather focus on > making our current, single approach faster and better (note that 0.4 > uses about half the method call overhead of 0.3 for load operations). > fair enough. I think I'm just a big fan of the ORM load features, but not of the (cascading) flush (save/update/delete) features. I am a control freak when it comes to the database. There was a stage when I did not like the sql generated from the ORM load as well, but recently (not sure which version) the sql it generates is almost ;-) as good as the one i write by hand
> If you want, just create a rudimentary object creation layer over the > normal SQL constructs. It would be more appropriate for this to be > something entirely separate from the existing orm module. > I was thinking along these lines. I am going to study your query.instances to get some hints Thanks for all the help. Huy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
