I do not know the optimization trick. I'd be interested to know! It would
be nice to not have to translate to and from the UUID type.
On Friday, May 19, 2017 at 4:04:55 PM UTC-7, Jonathan Vanasco wrote:
>
> side question - have you done any tests on how the UUID type queries as
> your
side question - have you done any tests on how the UUID type queries as
your database scales? It may make sense to do the shortuuid as a text
field, which you can put a substring index on. if you don't know that
postgresql optimization trick, I can explain it further.
--
SQLAlchemy -
The
On 05/19/2017 04:53 PM, Colton Allen wrote:
I get some issues when appending a model to an "orm.relationship"
(UnorderableType error). Which is annoying but can be worked around.
that doesn't sound like something in SQLAlchemy
I also use SQLAlchemy-Continuum which seems to have issues
I get some issues when appending a model to an "orm.relationship"
(UnorderableType error). Which is annoying but can be worked around.
I also use SQLAlchemy-Continuum which seems to have issues with retrieving
"orm.relationship"s. It will attempt to query using the shortuuid type
without
SQLAlchemy release 1.1.10 is now available.
Release 1.1.10 contains a short series of fixes to specific behaviors,
primarily in Core, as well as one issue with "delete orphan" cascade
when using inheriting mappers. No regressions were encountered since
1.1.9. Release 1.1.10 is recommended
On 05/18/2017 06:56 PM, jan.karstens via sqlalchemy wrote:
Upgrading a specific dialect (EXASOL) to 1.1.9 made me stumble across
this test (part of test_reflection.py):
https://github.com/zzzeek/sqlalchemy/blob/rel_1_1_9/lib/sqlalchemy/testing/suite/test_reflection.py#L737
def
looks fine to me? what did you have in mind?
On 05/18/2017 11:29 PM, Colton Allen wrote:
I want to make my UUID's prettier so I've gone about implementing a
ShortUUID column based on the shortuuid library[1]. The idea is to
store the primary key as a UUID type in postgres (since its
On 05/18/2017 08:42 PM, ben4ever wrote:
I'm writing a Progress OpenEdge dialect and when experimenting with the
dialect's default_schema_name I noticed that it is not automatically
used when creating a MetaData object without specifying a schema.
Here is an example where the SELECT statement
On Thu, May 18, 2017 at 11:56 PM, jan.karstens via sqlalchemy <
sqlalchemy@googlegroups.com> wrote:
> Upgrading a specific dialect (EXASOL) to 1.1.9 made me stumble across this
> test (part of test_reflection.py):
>
> https://github.com/zzzeek/sqlalchemy/blob/rel_1_1_9/lib/
>
