Re: [sqlalchemy] Re: SQLAlchemy 1.2.0b1 released

OK, thank a lot ! Le jeudi 13 juillet 2017 06:01:45 UTC+3, Mike Bayer a écrit : > > this is how that would have to be mapped, hypothetically: > > class EngineerBase(Person): > __tablename__ = 'engineer' > > id = Column(ForeignKey('person.id'), primary_key=True) > engineer_name =

Re: [sqlalchemy] Re: SQLAlchemy 1.2.0b1 released

this is how that would have to be mapped, hypothetically: class EngineerBase(Person): __tablename__ = 'engineer' id = Column(ForeignKey('person.id'), primary_key=True) engineer_name = Column(String(30)) __mapper_args__ = { 'polymorphic_load': 'selectin' } class

Re: [sqlalchemy] Re: SQLAlchemy 1.2.0b1 released

Here a MCWE : from sqlalchemy import Table, Column, Integer, String, ForeignKey, create_engine from sqlalchemy.orm import Session from sqlalchemy.ext.declarative import declarative_base Base = declarative_base() class Person(Base): __tablename__ = 'person' id = Column(Integer,

Re: [sqlalchemy] Re: SQLAlchemy 1.2.0b1 released

I have a mixed configuration with both joined and single table subclasses in a two-levels inheritance (like that ), so selectin seems to be the right choice for me. Le jeudi 13 juillet 2017 01:09:50 UTC+3, Mike Bayer a écrit : > >

Re: [sqlalchemy] Re: SQLAlchemy 1.2.0b1 released

On Wed, Jul 12, 2017 at 4:54 PM, wrote: > I noticed that {'polymorphic_load': 'selectin'} on single table inheritance > can make several SQL queries unnecessarily. well "selectin" loading would be inappropriate for single table inheritance because you are telling it to

[sqlalchemy] Re: SQLAlchemy 1.2.0b1 released

I noticed that {'polymorphic_load': 'selectin'} on single table inheritance can make several SQL queries unnecessarily. Le mercredi 12 juillet 2017 22:02:04 UTC+3, yoch@gmail.com a écrit : > > Very awaited version for me (because the selectin) ! > > I tested in my code both the eagerload and

[sqlalchemy] Re: SQLAlchemy 1.2.0b1 released

Very awaited version for me (because the selectin) ! I tested in my code both the eagerload and the polymorphic usages, and everything works perfectly. Thank you Mike Le lundi 10 juillet 2017 16:44:03 UTC+3, Mike Bayer a écrit : > > SQLAlchemy release 1.2.0b1 is now available. > > This is the

Re: [sqlalchemy] Re: SQLAlchemy 1.2.0b1 released

Great! Thank you!. Good to know the behavior hasn't changed. We have a lot of "read-only" routes or database-free routes which rely on the "lazy" transaction/connection behavior for performance. I was worried the new flag could create db connectivity per-request when the session is

Re: [sqlalchemy] Re: SQLAlchemy 1.2.0b1 released

the Session doesn't pull the connection from the engine until you do a query or call session.connection(), session.execute(), etc. This is because the Session supports multiple engines simultaenously and it doesn't know which one to use until it's asked to query something. On Tue, Jul 11, 2017 at

Re: [sqlalchemy] Re: SQLAlchemy 1.2.0b1 released

On Tuesday, July 11, 2017 at 10:27:15 AM UTC-4, Mike Bayer wrote: > > So the note for this is at: > > > http://docs.sqlalchemy.org/en/latest/changelog/migration_12.html#pessimistic-disconnection-detection-added-to-the-connection-pool > > > then in the main docs, the new flag replaces the

Re: [sqlalchemy] Re: SQLAlchemy 1.2.0b1 released

On Mon, Jul 10, 2017 at 5:58 PM, Jonathan Vanasco wrote: > > > On Monday, July 10, 2017 at 9:44:03 AM UTC-4, Mike Bayer wrote: >> >> * Connection pool pre-ping - The connection pool now includes an >> optional "pre ping" feature that will test the "liveness" of a pooled >>

[sqlalchemy] Re: SQLAlchemy 1.2.0b1 released

On Monday, July 10, 2017 at 9:44:03 AM UTC-4, Mike Bayer wrote: > > * Connection pool pre-ping - The connection pool now includes an > optional "pre ping" feature that will test the "liveness" of a pooled > connection for every connection checkout, transparently recycling the > DBAPI