I built 1.0.7dev from source and can verify that it resolved the issue we
were seeing.
Thanks!
Troy
On Wednesday, July 1, 2015 at 12:20:17 PM UTC-5, Michael Bayer wrote:
>
> resolved in master / rel_1_0
>
>
> On 7/1/15 1:01 PM, Mike Bayer wrote:
>
> after two reports, it is:
> https://bitbu
resolved in master / rel_1_0
On 7/1/15 1:01 PM, Mike Bayer wrote:
after two reports, it is:
https://bitbucket.org/zzzeek/sqlalchemy/issue/3469/comparison-in-persistencepy-can-trip-up-on
On 7/1/15 12:23 PM, Troy Toman wrote:
I am seeing a behavior similar to Issue #3402 but it exists in
SQL
after two reports, it is:
https://bitbucket.org/zzzeek/sqlalchemy/issue/3469/comparison-in-persistencepy-can-trip-up-on
On 7/1/15 12:23 PM, Troy Toman wrote:
I am seeing a behavior similar to Issue #3402 but it exists in
SQLAlchemy 1.0.6 and it involves using geoalchemy2. I have filed an
is
so as these issues tend to be reported in pairs, literally there is a
similar issue against geoalchemy2 where the same code is causing a
problem. 0.9 does this same comparison but it doesn't attempt to
evaluate the __bool__ of the object so I'll fix that:
https://bitbucket.org/zzzeek/sqlalch
I am seeing a behavior similar to Issue #3402 but it exists in SQLAlchemy
1.0.6 and it involves using geoalchemy2. I have filed an issue there but
since it is behaving differently in sqlalchemy 0.9.3, I wanted to raise it
here as well.
Test program:
import geoalchemy2
from sqlalchemy imp
Thanks for the response and the link to the associated method, there was
indeed a numpy datatype (not) being serialized on the linux platform
codebase.
Numpy has become second nature; I apparently cannot distinguish between
it's errors and python errors!
On Saturday, June 27, 2015 at 1:02:00
Mike Bayer writes:
> On 6/30/15 6:56 PM, Lele Gaifax wrote:
>> With the approach above custom column types used by the "new_table" are not
>> playing their "magic", and I currently must repeat it within the "adapt()"
>> function.
>
> I assume you mean the data you're getting back from old_table i
