[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 =

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

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 http://docs.sqlalchemy.org/en/latest/changelog/migration_11.html#change-3514 and

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] Re: A "after flush before commit" event

Hey Mike, Thanks for taking the time to answer all of these questions! I think what we're looking for is a way to perform some actions immediately before "COMMIT" is sent to the database. The current solutions (as far as I can understand them) all have some drawbacks: *Perform actions in

Re: [sqlalchemy] Batching INSERT statements

> > if you're using Postgresql, there's a vastly easier technique to use > which is just to pre-fetch from the sequence: > identities = [ > val for val, in session.execute( > "select nextval('mytable_seq') from " > "generate_series(1,%s)" % len(my_objects)) >

[sqlalchemy] How do Insert statements for single-table inheritance tables get batched together?

Hello! SQLAlchemy has the (really useful) behavior of batching together inserts when all the primary keys are defined. It looks like it groups similar tables together (while maintaining insert order ) to minimize the number of Insert statements sent to the database. I'm unsure what the

Re: [sqlalchemy] How do Insert statements for single-table inheritance tables get batched together?

I ran some tests using raw psycopg2 on my local computer, and also ran some tests with SQLAlchemy. I misunderstood a few things in my tests above, but I've explained the tests below and think they are more accurate. *Context:* - Each test was run 5 times and averaged. - Both the python and

[sqlalchemy] Batching INSERT statements

Hello! I've spent some time looking at SQLAlchemy's ability to batch inserts, and have a few questions about bulk_save_objects (and flushing in general). Two statements that I think are true: 1. Right now, bulk_save_objects does not fetch primary keys for inserted rows (unless

Re: [sqlalchemy] Polymorphic selectin bug which incorrectly caches queries

Oops, missed the Benchling reference in there. Thanks! On Sunday, June 24, 2018 at 7:09:51 PM UTC-7, Mike Bayer wrote: > > other than the imports and missing database setup I had to re-write ( > :) ), great test! issue is logged at > >

[sqlalchemy] Polymorphic selectin bug which incorrectly caches queries

Hello! We noticed some weird behavior where our tests were affecting one another, and I tracked it down to what I believe is a SQLAlchemy bug. It appears that performing a particular query with a joinedload can alter future queries that are run without the same joinedload. This appears to only

Re: [sqlalchemy] Non-deterministic behavior when setting relationships (1.2 regression)

Thanks so much Mike! I appreciate and am always amazed by your helpfulness and responsiveness. On Wednesday, January 24, 2018 at 6:36:24 PM UTC-8, Mike Bayer wrote: > > 1.2.2 is released w/ this fix > > On Wed, Jan 24, 2018 at 10:16 AM, Mike Bayer > wrote: > > the

[sqlalchemy] Non-deterministic behavior when setting relationships (1.2 regression)

Hello! We're currently in the process of upgrading from SQLAlchemy 1.1.11 to 1.2.1 (we're super excited about selectin!), and noticed some non-deterministic behavior in one of our tests. Here is the minimal repro that I was able to find: class A(db.Model): __tablename__ = 'a' id =

[sqlalchemy] How to have SQL IF in sqlalchemy

teams.department = 'hr' and (employee_managers.name = 'vineet' OR employee_managers.name IS NULL) where my models look like this: class EmployeeTeam(db.Model): __tablename__ = 'teams' id = db.Column(db.Integer, primary_key=True) name = db.Column(db.String(140), nullable=False) department