[sqlalchemy] Re: Bug report with JSON nulls in 1.1.x

A related issue (that seems like a bug) happens when reading attribute values after a flush, but before a commit. In this scenario, I set the default=JSON.NULL in both columns class A(db.Model): __tablename__ = 'a' id = db.Column(db.Integer, primary_key=True) column1 =

Re: [sqlalchemy] Re: Bug report with JSON nulls in 1.1.x

On Tue, Jul 18, 2017 at 2:12 AM, wrote: > A related issue (that seems like a bug) happens when reading attribute > values after a flush, but before a commit. In this scenario, I set the > default=JSON.NULL in both columns > With "default=JSON.NULL", it seems like the value

Re: [sqlalchemy] Re: Bug report with JSON nulls in 1.1.x

On Tue, Jul 18, 2017 at 2:12 AM, wrote: > A related issue (that seems like a bug) happens when reading attribute > values after a flush, but before a commit. In this scenario, I set the > default=JSON.NULL in both columns > class A(db.Model): > __tablename__ = 'a' > >

Re: [sqlalchemy] Bug report with JSON nulls in 1.1.x

On Tue, Jul 18, 2017 at 12:47 AM, wrote: > Hello, I'd like to report a bug report regarding JSON nulls and > underscore-prefixed attributes as we're upgrading from 1.0.17 to 1.1.11. > > I read through the behavior at >

Re: [sqlalchemy] Bug report with JSON nulls in 1.1.x

On Tue, Jul 18, 2017 at 10:31 AM, Mike Bayer wrote: > On Tue, Jul 18, 2017 at 12:47 AM, wrote: >> Hello, I'd like to report a bug report regarding JSON nulls and >> underscore-prefixed attributes as we're upgrading from 1.0.17 to 1.1.11. >> >> I

Re: [sqlalchemy] Potential bug with .exists() queries and subqueryloads

On Tue, Jul 18, 2017 at 2:13 PM, wrote: > Hello, I'm running into some difference in behavior for .exists() in > SQLAlchemy 1.0.17 and 1.1.11, related to subqueryloads. > > > class A(db.Model): > __tablename__ = 'a' > > id = db.Column(db.Integer, primary_key=True) >

Re: [sqlalchemy] Potential bug with .exists() queries and subqueryloads

> > however, I can't think of any reason public use of .subquery() or > .exists() would ever *want* eagerloaded options to take place since by > definition .subquery() and .exists() are never used to load objects. > So in 1.2 I'll propose to make this automatic > Yep, I agree with this!

Re: [sqlalchemy] Bug report with JSON nulls in 1.1.x

> > OK, this is great, it's likely not the "underscore" as much as that > the attribute is named differently from the column. I will look to > confirm this and set up a complete bug report, thanks! > Ah, that makes a lot more sense. Thanks for looking into that! Above, you are looking at

[sqlalchemy] Potential bug with .exists() queries and subqueryloads

Hello, I'm running into some difference in behavior for .exists() in SQLAlchemy 1.0.17 and 1.1.11, related to subqueryloads. class A(db.Model): __tablename__ = 'a' id = db.Column(db.Integer, primary_key=True) b_id = db.Column(db.Integer, db.ForeignKey('b.id'), nullable=False) b

Re: [sqlalchemy] session.add() neglecting some of my objects to be added

Thanks Mike, indeed, that was the problem. I solved it using an "ad hoc" copy function. This is the solution that worked for me in case somebody else incurs in the same mistake I did def copy_sqla_object(obj, omit_fk=True): """Given an SQLAlchemy object, creates a new object (FOR WHICH THE