Can’t make the Composite Comparator work…

17 views
Skip to first unread message

jens.t...@gmail.com

unread,
Sep 16, 2022, 4:38:38 AM9/16/22
to sqlalchemy
Hello,

I’m noodling through the Composite Column Types examples, and can’t make it work. Based on the code on that page I put together a minimal, reproducible example (attached) which fails with

Traceback (most recent call last):
  File "/path/to/test.py", line 75, in <module>
    assert v1.start > v2.start
TypeError: '>' not supported between instances of 'Point' and 'Point'

Why is that? What am I missing? I expected to see SQL generated that implements the “greater than” between two Point instances (or perhaps Vertex instance, not sure, probably not).

Much thanks!
Jens
test.py

Simon King

unread,
Sep 16, 2022, 5:20:40 AM9/16/22
to sqlal...@googlegroups.com
(I haven't used any of these features, so the following is just a guess)

In your assertion, you are comparing two *Point instances*. The SQLAlchemy comparator_factory mechanism has not made any changes to the Point class itself, and Point doesn't define __gt__, hence your TypeError.

The point of the comparator_factory is to add class-level behaviour when you are building SQL expressions. In this case, you could write a query like this:

    query = dbsession.query(Vertex).filter(Vertex.start > Point(2, 2))

Hope that helps,

Simon

--
SQLAlchemy -
The Python SQL Toolkit and Object Relational Mapper
 
http://www.sqlalchemy.org/
 
To post example code, please provide an MCVE: Minimal, Complete, and Verifiable Example. See http://stackoverflow.com/help/mcve for a full description.
---
You received this message because you are subscribed to the Google Groups "sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy/149c1ae1-94af-4a4e-884c-171f72eb010bn%40googlegroups.com.

jens.t...@gmail.com

unread,
Sep 16, 2022, 5:52:34 AM9/16/22
to sqlalchemy
Thank you Simon!

That worked indeed and makes a lot of sense. I think I misinterpreted the documentation a bit in that sense; it did puzzle that SQLA would patch all these mapped objects…

Based on your example:

>>> dbsession.query(Vertex).filter(Vertex.start > Point(2, 2)).all()
[<__main__.Vertex object at 0x1065f5690>]

Cheers,
Jens
Reply all
Reply to author
Forward
0 new messages