I don't know that customizing instrumentationmanager is all you'd need. There's lots of bookkeeping occurring with instancestate that takes time and is related to state tracking and persistence. The whole need for __setstate__ is due to the instancestate object. Not including it suggests an entirely new system that at most would consume rows from the orm.Query and route them into this alternate system.
Of course it's not impossible, but the options here would kind of be between implementing your own object instrumentation layer completely separate from that of sqlalchemys orm, which after all is just one style of orm that can be built upon the Core, and just waiting for technologies like pypy to be fully ready (which it mostly is). Performance with sqla aims to be "good enough" with techniques like pypy and horizontal scaling to offset CPU issues. If someone wanted to fund/offer to rewrite instancestate in C, as some other ORM was fortunate enough to have, that's yet another route. Sent from my iPhone On Feb 18, 2012, at 6:50 PM, Andrey Popp <8may...@gmail.com> wrote: > Hello, > > I have a bunch of tables which I only read from and store entities > in memcached. Profiler shows me my app spends a significiant amount of time in > __setstate__. So I want SQLAlchemy to: > > 1. load those objects from database > > 2. do not track their state > > 3. still have the ability to use read-only objects in relationships, so I can > create some non read-only object and relate it to some read-only object > > If I understand correctly I need to provide implementation of > sqlalchemy.orm.interfaces.InstrumentationManager which simply does almost > nothing, e.g. manages instance state in instance.__dict__. Is that right? Or I > need to do much more to achieve my goals? And does my goals make any sense or > this is impossible in SQLAlchemy at all? > > I've already started to implement InstrumentationManager and have one more > question regarding that. I've installed instrumentation finder but it seems I > can't have different instrumentation manager for class which has relationship > defined to class with standard sqlalchemy.orm.intrumentation.ClassManager -- > does it mean I need completely isolate classes with different instrumentation > managers from each other? If yes, that means 3. from the above list is > impossible, so can I somehow workaround this restriction? > > Thanks in advance! > > -- > 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 > sqlalchemy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sqlalchemy?hl=en. > -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
