I actually deleted my post on further consideration of this problem, I guess it lagged a bit so you got to it :) If this was implemented I'd rather it work with a new MapperProperty that takes the name of the attribute on the class to access instead of automatically detecting which attributes on the class were descriptors and which aren't (obviously, you don't want to be able to do stupid stuff like .filter_by(_private_variable_here=item). I don't currently have time to submit a patch for that kind of behavior.
On Nov 20, 9:54 am, "Gaetan de Menten" <[EMAIL PROTECTED]> wrote: > On Nov 20, 2007 3:12 PM, Chris M <[EMAIL PROTECTED]> wrote: > > > I think it's a good idea, if Mike agrees then I will submit a patch to > > do this later today. (Except MyClass.my_prop and my_prop_name won't be > > equiv, > > I never said that's what I wanted. Notice that in my "example", i > speak about filter and filter_by. > > > you'll have to have whatever your property returns support > > __eq__) > > Of course. > > > > > > > On Nov 20, 4:37 am, "Gaetan de Menten" <[EMAIL PROTECTED]> wrote: > > > Hi people, > > > > I have some classes with "standard python" properties which target > > > another python object and also uses several columns in the database. I > > > also got a global factory function to create an instance of that > > > target object out of the value of the columns (the class of that > > > target object can vary). > > > > Now, I'd like to use those properties in filter criteria, as so: > > > > session.query(MyClass).filter(MyClass.my_prop == value)... > > > session.query(MyClass).filter_by(my_prop_name=value)... > > > > I've tried using composite properties for that (passing the factory > > > function instead of a composite class), and it actually works, but I'm > > > a little nervous about it: can I have some bad side effect provided > > > that in *some* cases (but not always) the target object is loaded from > > > the database. > > > > I also dislike the fact I have to provide a __composite_values__ on > > > all the possible target classes, while in my case, I would prefer to > > > put that logic on the property side. I'd prefer if I could provide a > > > callable which'd take an instance and output the tuple of values, > > > instead of the method. Would that be considered a valid use case for > > > composite properties or am I abusing the system? > > > > I've also tried to simply change those properties to descriptors so > > > that I can override __eq__ on the object returned by accessing the > > > property on the class. This worked fine for "filter". But I also want > > > to be able to use filter_by. So, I'd wish that > > > query(Class).filter_by(name=value) would be somehow equal to > > > query(Class).filter(Class.name == value), but it's not. filter_by only > > > accepts MapperProperties and not my custom property. > > > > So what do people think? > > > > -- > > > Gaëtan de Mentenhttp://openhex.org > > -- > Gaëtan de Mentenhttp://openhex.org --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
