On Sat, Oct 22, 2022, at 6:57 AM, Lele Gaifax wrote: > Hi, > > as stated in > https://docs.sqlalchemy.org/en/20/dialects/postgresql.html#range-and-multirange-types, > > in SA 2.0 the PG "range" (and "multirange") types are wrapped in a new > Range class, while the underlying driver-specific class is "hidden" > within the dialect implementation. > > This means that many operations that were previously exposed to the > Python logic are not available anymore, and I'm not sure if that is > intentional, not-yet-implemented functionalities or instead just me > missing something.
we were going for the lowest common denominator of functionality, which was to be able to persist and load Range objects. If you look at asyncpg's Range type, it's very basic: https://github.com/MagicStack/asyncpg/blob/eccdf61afb0116f9500f6fb2f832058ba8eb463e/asyncpg/types.py#L42 We looked at the methods that psycopg2's Range has and they seemed to be related related to psycopg2's own internal needs, such as the comparison operator implementations, which don't make any real sense and are documented as "arbitrary": https://github.com/psycopg/psycopg2/blob/20bb48666312e6f4747d1f6187f520c812f29591/lib/_range.py#L159 More obvious methods like issubset and issuperset (https://github.com/MagicStack/asyncpg/blob/master/asyncpg/types.py#L110) are easy to add and are just a pull request / issue away. as for psycopg2's __contains__, that also looks very simple but I'd rather have it as an explicit name like "contains_value()". As far as the Multirange type in psycopg3, I looked at that and the features it had seemed to be redundant vs. what you can do with a plain list, and indeed asyncpg implements multirange using lists of Ranges which IMO is much more natural and easy to work with. > > For example, one of the trickiest things I would need to reimplement is > the Python-side equivalent of the "<@" operator, that checks whether an > element is contained in a range: in SA 1.x this was readily exposed by > the driver implementation, usually by a `__contains__` method > (see https://github.com/psycopg/psycopg2/blob/master/lib/_range.py#L121 > for psycopg2). Similar methods are a PR (with tests) away from being included. > > What do you foresee, that the Range class should/will "proxies" those > capabilities, or instead that I should change (pseudo)code like:: Range is a really simple dataclass so adding a few simple value methods contains_value(), issubset(), issuperset() is a PR (with tests) away. there's no need to "proxy" things, these are pretty obvious methods to just implement directly. I would just disagree with psycopg2's more nonsensical methods like `__lt__`, `__gt__`, etc. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy/65c1d0aa-bf26-459c-8cc2-60f9083292fc%40app.fastmail.com.
