Michael wrote: > attached is an approach that uses just the tiniest amount of > awareness of how a mapper works, to do the whole optimized > loading scenario ahead of time, and you get an object with your > two distinct "pro" and "con" relationships, no list decoration > or anything needed. the appropriateness of this approach comes > from the fact that your optimization case is a load-time > optimization, therefore put the complexity at load time (which > is easier to deal with since it doesnt have to be concerned > with collection mutability).
This is great! So much simpler! I'm wondering, when storing partitioned instances: > instance.pro.append(class_mapper(Position)._instance(context, row, None)) ...does this need to go through the instrumented append() method or can I add them through my own, non-list method? (When these mini-collection lists are backed by a collection class that manages ordering attributes, it's super useful to be able to differentiate between appends coming from from database load vs user code.) -jek --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
