what about adding a docopy=True (or dont_copy=False) to all methods that could be both copy_generative and modify-in-place? via some generic self=self.copy_if_required() func? Then one can choose at which point to split+copy
> let me summarize things that im thinking we do: > > - we want to go with the joinpoint concept here, where join() > starts from the beginning, and join(None)/reset_joinpoint brings it > back. join() is used to add a join and also modify the joinpoint of > the query, so that you can add more criterion using filter() or > filter_by () or others. I think this particuar tweak would > probably even be OK to put in the current trunk for release 0.3.8 > unless people think its going to create problems...the only > backwards-incompatible change being a join() starts from the > beginning, not the previous join(). > > - i think filter_by(['list','of','properties'], **kwargs), i.e. an > optional, positional string/list-of-strings argument, should also > be present, and it will create the joins and criterion using table > aliases, and will not be related to joinpoint at all. apparently > django does this, and it would let us define criterion for multiple > overlapping paths, such as q.filter_by(['a', 'b, 'c'], > d=x).filter_by (['a', 'b', 'e'], d=x). thats something that you > cant do with the straight join() alone (but of course you can do > with explicit aliases and filter()/select_from()). > > - the "auto find me a property" behavior is gone. not sure if I > want to remove it from select_by() and friends, i think it should > probably remain in those in a deprecated state. > > - ClauseElement support would be removed from filter_by(). you can > just use filter() for those. the older _by() methods, which i want > to deprecate, would be left alone for backwards compatibility. > > - i want to deprecate all the criterion methods that are not > filter, i.e. all the selects and most of the gets (except straight > get()). selecting from a full statement we can do with > query.from_statement (<select statement>), the argument of which is > a select() or a string. > > deprecating select() and select_by() is to create a single simple > interface to query based on the more flexible filter(). but it > does mean a bit more typing in many cases. I would hope everyone > is OK with that. > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
