Does orm.synonym's comparator_factory work?

[Arturo Sevilla]

Hi,

I have a mapping between a table row and a python field, for which I have a synonym. I've read the documentation and it says: "Each of column_property(), composite(), relationship(), and comparable_property() accept an argument called comparator_factory." For which I assume that synonym() doesn't have a comparator_factory, however when I peeked into the library's code I saw this definition:

def synonym(name, map_column=False, descriptor=None, 

                        comparator_factory=None, doc=None):

Does this means that you can actually customize a comparator_factory for synonym? I ask because in my "proxied" mapped column I have a custom comparator_factory which defines a "method" for that property so I can do something like filter(my_prop.my_method()). However, this method doesn't get proxied by orm.synonym, with or without defining the same comparator_factory in orm.synonym(). Part of my mapper is:

        '_geolocation': orm.composite(GeoPoint, event.c.GeoLatitude, 

                                      event.c.GeoLongitude,

                                      comparator_factory=GeoPointComparator),

        'geolocation': orm.synonym('_geolocation',

                                   comparator_factory=GeoPointComparator)

I really don't have a problem using filter(Klass._geolocation.near(param1, param2)) for my code (near being defined in GeoPointComparator). I made this post to see if someone with more insight can help to clarify this, so that I don't have to peek very deeply into the code in order to look for the answer of this behavior.

Thanks

[Michael Bayer]

If you pass a PropComparator class to the comparator_factory argument of "synonym()", an instance of that class will be used when Python comparison operations are invoked upon the mapped attribute at the class level. Whatever behavior it defines from there is what takes place, which should include the __getattr__() proxying that would locate your "near()" method.

If things don't work, provide a short, succinct, working (meaning, shows the problem) test case and we can see what might be the issue.

[Arturo Sevilla]

As a follow up to this thread, I've seen in the code in version 0.7.2 that comparator_factory is no longer working for CompositeProperty. Is this a bug?

Reference:

http://www.sqlalchemy.org/trac/browser/lib/sqlalchemy/orm/descriptor_props.py#L75

You can see that in the constructor there is no way in specifying a comporator_factory. If this is not a bug, then I guess the documentation is wrong: http://www.sqlalchemy.org/docs/orm/mapper_config.html#sqlalchemy.orm.composite

Thanks

[Michael Bayer]

I cannot locate the rationale for this despite a dim memory that there was one, so this is a bug with ticket 2248 created at http://www.sqlalchemy.org/trac/ticket/2248 , with a restorative patch attached.  If someone can provide tests for the attached patch using a custom comparator and there's no issue (I'm assuming you might have one) the feature can be re-implemented.

--
You received this message because you are subscribed to the Google Groups "sqlalchemy" group.
To view this discussion on the web visit https://groups.google.com/d/msg/sqlalchemy/-/j5XfGj-vyZAJ.
To post to this group, send email to sqlal...@googlegroups.com.
To unsubscribe from this group, send email to sqlalchemy+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.

[Arturo Sevilla]

I will see if later today I can provide some tests, or by tomorrow. I think the basic rationale is that a composite property should behave like a regular mapped property, and those have a comparator_factory, although I know this is probable a lame argument.

[Michael Bayer]

oh...sorry I meant the rationale for it being removed in 0.7, it had something to do with the internals of the whole thing.   Perhaps I just forgot to re-implement, not sure.

On Aug 6, 2011, at 7:24 PM, Arturo Sevilla wrote:

I will see if later today I can provide some tests, or by tomorrow. I think the basic rationale is that a composite property should behave like a regular mapped property, and those have a comparator_factory, although I know this is probable a lame argument.

--
You received this message because you are subscribed to the Google Groups "sqlalchemy" group.

To view this discussion on the web visit https://groups.google.com/d/msg/sqlalchemy/-/J9HVsxHYg60J.