So far I've been having a great time with generative query-building methods... build a query, filter it, order it, etc...
Is there a way to, uh, de-generate a query? E.g., q0 = session.query(someclass) q1 = q.filter(col == value) q2 = q.filter(othercol == othervalue) # all of the above works great, of course # but how about if we could: q3 = q.remove_filter(othercol == othervalue) q4 = q.remove_filter(col == value) ...it would be great if executing q4 gave the same results as executing q0, and if q3 gave the same results as q2. Even nicer if the filters could be removed out of order relative to the order in which they were added -- but I have a feeling that could lead to unacceptably ambiguous behavior. I'm working on a simple GUI view/query window that lets me assign search values to fields(columns), with text auto-completion, and puts up the result set from my items database on-the-fly, in a viewable grid (etc etc). Every time I specify a value in a field which was formerly null, the search criterion is narrowing. SQLAlchemy made this very easy: just add to the current query a filter for the corresponding field/value. Works great. But then say I clear one of my search fields, basically telling the app that I want to remove the restriction I had formerly placed on that field. That would correspond to removing a filter that was previously added to the query. As it stands now, this is not actually difficult to do: I just store a set of filters that have been added so far, and when the user clears one of the search field boxes, the query is rebuilt from scratch with all of the other stored filters, just without the one corresponding to the newly unrestricted column. It would be nicer/cleaner/straightforward-er if I didn't have to rebuild the query at that point; if I could just de-filter or de- select by parts. Am I barking up an odd tree here? I understand that selects/filters/etc. can't be assumed to be commutative; i.e. that you can't necessarily expect query.filter(one).filter(two).filter(three) == query.filter(two).filter(one).filter(three). On the other hand, in the use case I'm addressing, I'm staying within a single table in a db, with no joins, no added columns, no functions, just a nice clean relation with seven columns. Thoughts? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
