On Nov 5, 2008, at 5:56 PM, Adam Ryan wrote:
> > > Big fan, first post. > > I need to store a result set and subsequently act on it ( add to set, > select from set, remove from set, etc.) in ways that stored filters > can't accommodate; lots of arndom serial steps, removing and adding > specific records, filtering by the results of other joined table > queries, etc. > > There are two ways I've done this in the past. Both work, but leave > me queasy. > > 1. Store a list of ids, and use them accordingly, ie: > > # My current query > query = query.filter( ... ) > > # And I'm selecting from a previous set > query = query.filter( or_( *[ MyObject.c.id==id for id in > result_set ] ) ) > > ... > > # And then store this set > result_set = [ obj.id for obj in col ] > > 2. Create and subsequently alter a table in the database with one > field (id) that I use to join to the table I'm querying. This is a > unique table for each user that eventually gets cleaned up. > > Neither method seems optimized nor scalable. Large sets make the > former unwieldy, many users make the later troublesome. Any thoughts > on a better way? the way that relational tools like SQLA approach this is by representing a "stored" result set not as a list of specific objects or identifiers, but as the criterion which is used to retrieve that data, which I guess is what you mean by a "stored filter". The various add/remove operations you describe are made compatible with this approach by representing each change operation in the unit of work, and then flushing all pending unit of work changes to the database before any actual result-returning execution of the query. The database is used for all set representation, and the client side strictly brokers communcations with the database in a lazily- evaulating style. SQLA's session sets autoflush=True by default so that you get this effect, and it also keeps a transaction going so that back and forth communication with the database remains pending until an explicit commit. So to suggest an alternative to this you'd have to describe what additional behavior is needed, such as is it an issue of overly complex filter criterion being inefficient on the server side, or you're trying to reduce the number of persist operations, or some kind of long-transaction-spanning concern. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
