On Feb 19, 2012, at 5:24 AM, Andrey Popp wrote: > Regarding rationale let me describe where I can find this feature useful: > > * You have a part of you tables read-only, so you only query data from them. > > SQLAlchemy doesn't have to track changes on objects of classes mapped to > these tables. According to this stackoverflow post[1] we can get a "not so > negligible" performance gain here. > > * We can map same table on same class using different mappers (one in > "read-only mode" and other in "persistence mode"). > > That way we can use "read-only mapper" to query data in case we don't want > to > change it and we can use "persistence mapper" otherwise. I believe this > will also lead to better correctness of application itself.
Hello, After reading your stackoverflow post (implying that a profile revealed much instrumentation that you don't need), it occurred to me that you could use SQLAlchemy to generate the SQL query which you then pass directly to an execute method on a the underlying session bind to bypass generating SQLAlchemy models. Ideally, you could further shrink the query by only requesting the columns you actually need in your calculations. This seems at least the least-instrusive approach before you jump to C. Cheers, M -- 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.
