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
>
> https://bitbucket.org/zzzeek/sqlalchemy/issues/4286/mappe
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
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 plan is to fix and release by
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 = db.Co
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 datab
Hey Mike,
Thanks again for the detailed explanations!
I went ahead and tested the code snippet you gave me - I'm not sure I
totally understand when this will change behavior though.
I tried the following code snippet:
(Snippet #1)
for i in xrange(10):
db.session.add(A(id=i))
db.session.flus
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 expected
>
> 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))
>
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 return_def
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 befor
>
> 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! Thanks
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
>
> 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 "a.
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 = db.Column('col
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
http://docs.sqlalchemy.org/en/latest/changelo
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)
16 matches
Mail list logo