On Nov 20, 2007, at 4:37 AM, Gaetan de Menten 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? im not totally understanding the "all possible target classes" concept here, you're creating classes on the fly ? if you are in fact creating new classes on the fly, i dont see whats so hard about tacking on a __composite_values__ to each one as well (i.e. dont you have a single function that is doing the generation ?) I dont understand what "put that logic on the property side" means otherwise. If you can show me some example code that might help, but I think you probably are abusing the system here and the MapperProperty idea that Chris mentioned is probably the way to go. > > > 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. > Well the general case of filter_by() and filter() awareness is accomplished via synonym(). the filter() part for synonym() doesnt work yet but we have ticket #801 to address that. this ticket will take the existing Python property and put an InstrumentedAttribute wrapper around it. But in this case you aren't making synonym(), you pretty much want a synonym() that doesn't target any particular column. Maybe we could expand ticket #801 to include that, or maybe make some new ticket for this. We'd just have another mapper function thats like synonym() but doesnt actually target a column, it just adds that name to the list of properties. But also, the target property, or something else, would have to provide the MapperProperty interface it as well, like Chris says. So a new kind of MapperPropery would be needed here. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
