Hi Diana Michael Bayer,
thanks for your help!
So, you both use sqlalchemy 0.8 and I use 0.7.9 and that explains our
different SQL queries.
Now, with the join_depth=1 parameter the unexplainable SQL queries
disappear and there is no more difference between lazy='subquery' and
subqueryload().
Well, anyone?
On Thursday, November 22, 2012 1:42:07 AM UTC+4, Ivan Kalinin wrote:
Hellow, fellow developers!
I have run into and issue trying to use SQLAlchemy (0.7.4) and recent
pymssql (2.0.0).
Precisely, pymssql can not handle uuid.UUID objects as parameters (see
related post on
On 11/18/2012 03:48 PM, Michael Bayer wrote:
There's a lot of documentation on this, not sure how you're not finding it,
unless you're not using 0.8 (which is required):
1. documentation for SQL bind/result column processing:
Psycopg 2.4.6 will support them
(http://initd.org/psycopg/docs/extras.html#range-data-types).
Ranges are quite useful and play well with exclusion constraints.
Please add them. Thanks
On Friday, November 23, 2012 3:14:20 AM UTC+1, Michael Bayer wrote:
wow I sure wish postgresql would stop
Am 23.11.2012 14:34, schrieb philipt:
Psycopg 2.4.6 will support them
(http://initd.org/psycopg/docs/extras.html#range-data-types).
Ranges are quite useful and play well with exclusion constraints.
Yepp. I also often have ranges (not only time ranges) in my databases,
currently implemented
On Nov 21, 2012, at 4:42 PM, Ivan Kalinin wrote:
Hellow, fellow developers!
I have run into and issue trying to use SQLAlchemy (0.7.4) and recent pymssql
(2.0.0).
Precisely, pymssql can not handle uuid.UUID objects as parameters (see
related post on their ML here), but SA uses them
On Nov 23, 2012, at 12:57 AM, Gerald Thibault wrote:
I have a base class and 3 subclasses which inherit from it polymorphically. I
also have a mixin, which attempts to add a relation to the 'Extra' class,
which has a foreign key to the base class.
Here is the runnable test.
Issuing
On Nov 23, 2012, at 3:38 AM, Martin84 wrote:
Hi Diana Michael Bayer,
thanks for your help!
So, you both use sqlalchemy 0.8 and I use 0.7.9 and that explains our
different SQL queries.
Now, with the join_depth=1 parameter the unexplainable SQL queries disappear
and there is no more
On Nov 23, 2012, at 11:05 AM, Michael Bayer wrote:
Child refers to its parent via id_human, is a many-to-one - a Child can only
have *one* human. your script assigns newChild twice, once to newMen, once
to newWoman. assigning it to newWoman essentially removes it from newMen.
cancel
On Nov 23, 2012, at 3:38 AM, Martin84 wrote:
Hi Diana Michael Bayer,
thanks for your help!
So, you both use sqlalchemy 0.8 and I use 0.7.9 and that explains our
different SQL queries.
Now, with the join_depth=1 parameter the unexplainable SQL queries disappear
and there is no more
Hi Diana Michael Bayer,
thanks a lot for your help and time. I will use the workaround or change
the database schema.
Good to know, that sqlalchemy has such a helpful community!
Bye
Am Freitag, 23. November 2012 17:37:00 UTC+1 schrieb Michael Bayer:
On Nov 23, 2012, at 3:38 AM, Martin84
Thanks for the reply!
However, I see that MSSQL dialect contains a UNIQUEIDENTIFIER type that is
to represent similarly named column type. Looks like it should handle
issues of marshalling the values, not some custom type.
On Friday, November 23, 2012 7:39:50 PM UTC+4, Michael Bayer wrote:
In my own MSSQL work, we use character fields for UUIDs as the DBAs were not in
favor of trying to get UNIQUEIDENTIFIER to work. However, feel free to use
UserDefinedType to implement UNIQUEIDENTIFIER including whatever coercion
pymssql requires
Wait. I mean that SA _already_ has implemented UNIQUEIDENTIFIER over here:
https://bitbucket.org/sqlalchemy/sqlalchemy/src/0c8e0b613da3b2bf6e965e1e5c15b6b3e540368a/lib/sqlalchemy/dialects/mssql/base.py?at=default#cl-478
I believe that thing should be responsible for valid
marshalling/unmarshalling
ideally pymssql would know how (and are you saying that pyodbc does already?),
but sure, SQLA does all kinds of coercion. For now, your options are to use
the TypeDecorator recipe mentioned earlier around this UNIQUEIDENTIFIER type,
or send me a pull request with a pymssql-specific type
Wow, thanks! But that looks pretty complex. I believe a more valid way of
fixing the issue is a patch for pymssql itself - since it's relatively
simple and already available:
https://bitbucket.org/PuPSSMaN/pymssql/changeset/ed48708effdb481a9695e58876e223eb
I'll try to contact pymssql mantainer to
suppose I have the following tables (in pseudo-code)
User:
* userid
* name
Thing
* thingid
* name
* userid
Thing.user = relation(User, User.userid==Thing.userid)
Now, If I have the following query:
query =
session.query(Thing).option(joinedload('user')).join(User).filter(User.name
==
On Thu, 22 Nov 2012 21:24:08 -0500, Michael Bayer wrote:
there's a lot going on here, though an initial idea would be when mapping to
a __table__ that is in fact a select(), make that select() in terms of a
Table object, not the Inode mapped class. The columns as accessed from the
Inode class
18 matches
Mail list logo
