Hi!
I have finally completed the "port" of my application from SA 1.4 to SA
2.0b.
TL;DR I'm writing this report to ask an opinion about possible
"improvements" to the Range class.
Given that the previous state was already "clean" (that is, executing
the test suite with SQLALCHEMY_WARN_20=1 did not raise any warning), I
did not have big surprises (a loud applause here!).
The area that required lot of changes has been the introduction of the
new Range object: as said in previous emails this application uses
DATERANGE in many entities, and TSRANGE in a couple of cases.
The common modification has been replacing
from psycopg2.extras import DateRange
with
from sqlalchemy.dialects.postgresql import Range
and adapting the code accordingly, say from
validity = DateRange(now, then, '[]')
to
validity = Range(now, then, bounds='[]'')
most of that thru regexp search and replace and Emacs keyboard macros.
Not a big deal.
Where I had to spend more thinking has been in two differences, one
minor/cosmetic, the other more substantial.
On the former one, it would be nice if we could reduce the "distance"
between the new Range class and what popular drivers provide:
- "empty" vs "isempty": both asyncpg and psycopg have a "isempty"
property, we could either rename the "empty" attribute or add an
property alias
- bounds inclusiveness: both drivers expose that thru
"lower_inc"/"upper_inc" properties, while in SA we must say
`range.bounds[0] == '['`
- infinite bounds: likewise, they both provide "lower_inf"/"upper_inf"
properties, whereas we must say `range.lower is None and not
range.empty`
As you see, these are "syntactic sugar" differences, easily implemented
with some @properties.
What is more substantial, that required slightly more impacting changes
in a few cases, is that the SA Range does not have an exact notion of
its "type", i.e. there is no way to determine the data type of an empty
or infinite range.
For example, my app shows the period of validity of (say) a contract,
which storage is a daterange, either in a compact form (mm/dd/yy -
mm/dd/yy) or as a more verbose, human friendly message ("from Sun, 10
March 2022 to Fri, 15 March 2022"), in multiple languages, and taking
into account "infinite" variants. This was implemented with a generic
"strftime()" function taking either a date, a datetime, a DateRange or
DateTimeRange as argument, and depending on the kind it used different
gettext() messages to translate it to a string.
To emit different messages for "endless" date ranges and "endless"
datetime ranges, I had to modify the code path leading there, to bring
over the "original" kind of the range.
>From a different perspective, we had to invent a way to distinguish the
different kind of ranges also in the recent improvements to the Range
class, to be able to determine a "discrete step" for each of them.
So I wonder if it would be reasonable/doable/affordable if SA could grow
a "family" of classes, derived from current Range, one for each data
type, so that for example a DATARANGE column would be associated with a
DateRange instance.
What do you think?
ciao, lele.
--
nickname: Lele Gaifax | Dire che Emacs è "conveniente" è come
real: Emanuele Gaifas | etichettare l'ossigeno come "utile"
l...@etour.tn.it | -- Rens Troost
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sqlalchemy/87pmd4lat5.fsf%40metapensiero.it.
