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:
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
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
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
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:
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
Mike Bayer mike...@zzzcomputing.com 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
