Re: [sqlalchemy] relationship query_class in SQLAlchemy 1.4.0b3
tary anywhere about SQLAlchemy, the top
>> complaints are:
>>
>> 1. too magical, too implicit
>>
>> 2. what's wrong with just writing SQL?
>>
>> SQLAlchemy 2.0 seeks to streamline the act of ORMing such that the user
>> *is* writing SQL, they're running it into an execute() method, and they are
>> managing the scope of connectivity and transactions in an obvious way.
>> People don't necessarily want bloat and verbosity but they do want to see
>> explicitness when the computer is being told to do something, especially
>> running a SQL query. We're trying to hit that balance as closely as
>> possible.
>>
>> The above style also has in mind compatibility with asyncio, which we now
>> support. With asyncio, it's very important that the boundary where IO
>> occurs is very obvious. Hence the Session.execute() method now becomes the
>> place where users have to "yield". With the older Query interface, the
>> "yields" would be all over the place and kind of arbirary, since some Query
>> methods decide to execute at one point or another.
>>
>> Flask-SQLAlchemy therefore has to decide where it wants to go with this
>> direction, and there are options, including sticking with the legacy query
>> / dynamic loader, perhaps vendoring a new interface that behaves in the
>> flask-sqlalchemy style but uses 2.0-style patterns under the hood, or it
>> can go along with the 2.0 model for future releases. From
>> SQLAlchemy's point of view, the Query was always not well thought out and
>> was inconsistent with how Core worked, and I've wanted for years to resolve
>> that problem.
>>
>> - mike
>>
>>
>>
>>
>> On Thursday, February 25, 2021 at 2:21:43 PM UTC-8 Mike Bayer wrote:
>>
>>
>> this will be fixed in
>> https://github.com/sqlalchemy/sqlalchemy/issues/5981 where I've
>> reverted entirely some changes to AppenderQuery that made it work more in
>> 2.0 style. As Query is going to be present in 2.0, "dynamic" relationships
>> will remain also as legacy. They are superseded by explicit use of the
>> with_parent() filtering construct.
>>
>>
>>
>> On Thu, Feb 25, 2021, at 3:25 PM, Ahmed wrote:
>>
>> Hello,
>>
>> It seems that SQLAlchemy 1.4.0b3 ignores relationship() query_class
>> parameter. Here's the snippet that works with 1.3 but doesn't with 1.4:
>>
>> class Parent(db.Model):
>> __tablename__ = "todo"
>> id = db.Column(db.Integer, primary_key=True)
>> # ... Column mappings
>> children = db.relationship("Child",
>> backref="todo", query_class=DerivedQuery, lazy="dynamic")
>>
>> class Child(db.Model):
>> __tablename__ = "todo"
>> # ... Column mappings
>> parent_id = db.Column(db.Integer, db.ForeignKey("todo.id"))
>>
>> assert isinstance(p.children, DerivedQuery)
>>
>> In 1.4, children attribute is always an instance of AppenderQuery
>> regardless of the query_class value. I might have missed something above
>> though.
>>
>>
>>
>> --
>> SQLAlchemy -
>> The Python SQL Toolkit and Object Relational Mapper
>>
>> http://www.sqlalchemy.org/
>>
>> To post example code, please provide an MCVE: Minimal, Complete, and
>> Verifiable Example. See http://stackoverflow.com/help/mcve for a full
>> description.
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "sqlalchemy" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to sqlalchemy+...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/sqlalchemy/4454277c-b3a1-484e-b0e5-aef3e72eeb01n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/sqlalchemy/4454277c-b3a1-484e-b0e5-aef3e72eeb01n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>>
>> --
>> SQLAlchemy -
>> The Python SQL Toolkit and Object Relational Mapper
>>
>> http://www.sqlalchemy.org/
>>
>> To post example code, please provide an MCVE: Minimal, Complete, and
>> Verifiable Example. See http://stackoverflow.com/help/mcve for a full
>> description.
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "sqlalchemy" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to sqlalchemy+...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/sqlalchemy/087934f8-d7fb-4062-8b2a-9d623a2e7941n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/sqlalchemy/087934f8-d7fb-4062-8b2a-9d623a2e7941n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>>
>> --
>> SQLAlchemy -
>> The Python SQL Toolkit and Object Relational Mapper
>>
>> http://www.sqlalchemy.org/
>>
>> To post example code, please provide an MCVE: Minimal, Complete, and
>> Verifiable Example. See http://stackoverflow.com/help/mcve for a full
>> description.
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "sqlalchemy" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to sqlalchemy+...@googlegroups.com.
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/sqlalchemy/f161e6b7-b8b1-457c-bd96-b4e2494b52f8%40www.fastmail.com
>>
>> <https://groups.google.com/d/msgid/sqlalchemy/f161e6b7-b8b1-457c-bd96-b4e2494b52f8%40www.fastmail.com?utm_medium=email_source=footer>
>> .
>>
>
--
SQLAlchemy -
The Python SQL Toolkit and Object Relational Mapper
http://www.sqlalchemy.org/
To post example code, please provide an MCVE: Minimal, Complete, and Verifiable
Example. See http://stackoverflow.com/help/mcve for a full description.
---
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sqlalchemy/8c33f39c-1a9f-49cd-abfc-2d234a956d4dn%40googlegroups.com.
Re: [sqlalchemy] relationship query_class in SQLAlchemy 1.4.0b3
s is very obvious. Hence the Session.execute() method now becomes the
>> place where users have to "yield". With the older Query interface, the
>> "yields" would be all over the place and kind of arbirary, since some Query
>> methods decide to execute at one point or another.
>>
>> Flask-SQLAlchemy therefore has to decide where it wants to go with this
>> direction, and there are options, including sticking with the legacy query /
>> dynamic loader, perhaps vendoring a new interface that behaves in the
>> flask-sqlalchemy style but uses 2.0-style patterns under the hood, or it can
>> go along with the 2.0 model for future releases. From SQLAlchemy's
>> point of view, the Query was always not well thought out and was
>> inconsistent with how Core worked, and I've wanted for years to resolve that
>> problem.
>>
>> - mike
>>
>>
>>
>>
>>> On Thursday, February 25, 2021 at 2:21:43 PM UTC-8 Mike Bayer wrote:
>>>> __
>>>> this will be fixed in https://github.com/sqlalchemy/sqlalchemy/issues/5981
>>>> where I've reverted entirely some changes to AppenderQuery that made it
>>>> work more in 2.0 style. As Query is going to be present in 2.0, "dynamic"
>>>> relationships will remain also as legacy. They are superseded by
>>>> explicit use of the with_parent() filtering construct.
>>>>
>>>>
>>>>
>>>> On Thu, Feb 25, 2021, at 3:25 PM, Ahmed wrote:
>>>>> Hello,
>>>>>
>>>>> It seems that SQLAlchemy 1.4.0b3 ignores relationship() query_class
>>>>> parameter. Here's the snippet that works with 1.3 but doesn't with 1.4:
>>>>>
>>>>> class Parent(db.Model):
>>>>> __tablename__ = "todo"
>>>>> id = db.Column(db.Integer, primary_key=True)
>>>>> # ... Column mappings
>>>>> children = db.relationship("Child", backref="todo",
>>>>> query_class=DerivedQuery, lazy="dynamic")
>>>>>
>>>>> class Child(db.Model):
>>>>> __tablename__ = "todo"
>>>>> # ... Column mappings
>>>>> parent_id = db.Column(db.Integer, db.ForeignKey("todo.id"))
>>>>>
>>>>> assert isinstance(p.children, DerivedQuery)
>>>>>
>>>>> In 1.4, children attribute is always an instance of AppenderQuery
>>>>> regardless of the query_class value. I might have missed something above
>>>>> though.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> SQLAlchemy -
>>>>> The Python SQL Toolkit and Object Relational Mapper
>>>>>
>>>>> http://www.sqlalchemy.org/
>>>>>
>>>>> To post example code, please provide an MCVE: Minimal, Complete, and
>>>>> Verifiable Example. See http://stackoverflow.com/help/mcve for a full
>>>>> description.
>>>>> ---
>>>>> You received this message because you are subscribed to the Google Groups
>>>>> "sqlalchemy" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send an
>>>>> email to sqlalchemy+...@googlegroups.com.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/sqlalchemy/4454277c-b3a1-484e-b0e5-aef3e72eeb01n%40googlegroups.com
>>>>>
>>>>> <https://groups.google.com/d/msgid/sqlalchemy/4454277c-b3a1-484e-b0e5-aef3e72eeb01n%40googlegroups.com?utm_medium=email_source=footer>.
>>>
>>> --
>>> SQLAlchemy -
>>> The Python SQL Toolkit and Object Relational Mapper
>>>
>>> http://www.sqlalchemy.org/
>>>
>>> To post example code, please provide an MCVE: Minimal, Complete, and
>>> Verifiable Example. See http://stackoverflow.com/help/mcve for a full
>>> description.
>>> ---
>>> You received this message because you are subscribed to the Google Groups
>>> "sqlalchemy" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to sqlalchemy+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/sqlalchemy/087934f8-d7fb-4062-8b2a-9d623a2e7941n%40googlegroups.com
>>>
>>> <ht
Re: [sqlalchemy] relationship query_class in SQLAlchemy 1.4.0b3
ctionally extends
> sqlalchemy.orm.Query and pass the extended class to relationship and
> other constructs as well.
>
>
> yes so, SQLAlchemy 2.0's approach is frankly at odds with the spirit of
> Flask-SQLAlchemy.The Query and "dynamic" loaders are staying around
> largely so that Flask can come on board, however the patterns in F-S are
> pretty much the ones I want to get away from.
>
> 2.0's spirit is one where the act of creating a SELECT statement is a
> standalone thing that is separate from being attached to any specific class
> (really all of SQLAlchemy was like this, but F-S has everyone doing the
> Model.query thing that I've always found to be more misleading than
> helpful), but SELECT statements are now also disconnected from any kind of
> "engine" or "Session" when constructed.
>
> as for with_parent(), with_parent is what the dynamic loader actually uses
> to create the query. so this is a matter of code organization.
>
> F-S would have you say:
>
> user = User.query.filter_by(name='name').first()
> address = user.addresses.filter_by(email='email').first()
>
> noting above, there's no "Session" anywhere. where is it? Here's a
> Hacker News comment lamenting the real world implications of this:
> https://news.ycombinator.com/item?id=26183936
>
> SQLAlchemy 2.0 would have you say instead:
>
> with Session(engine) as session:
> user = session.execute(
> select(User).filter_by(name='name')
> ).scalars().first()
>
>address = session.execute(
>select(Address).where(with_parent(user,
> Address.user)).filter_by(email='email')
>).scalars().first()
>
> Noting above, a web framework integration may still wish to provide the
> "session" to data-oriented methods and manage its scope, but IMO it should
> be an explicit object passed around. The database connection / transaction
> shouldn't be made to appear to be inside the ORM model object, since that's
> not what's actually going on.
>
> If you look at any commentary anywhere about SQLAlchemy, the top
> complaints are:
>
> 1. too magical, too implicit
>
> 2. what's wrong with just writing SQL?
>
> SQLAlchemy 2.0 seeks to streamline the act of ORMing such that the user
> *is* writing SQL, they're running it into an execute() method, and they are
> managing the scope of connectivity and transactions in an obvious way.
> People don't necessarily want bloat and verbosity but they do want to see
> explicitness when the computer is being told to do something, especially
> running a SQL query. We're trying to hit that balance as closely as
> possible.
>
> The above style also has in mind compatibility with asyncio, which we now
> support. With asyncio, it's very important that the boundary where IO
> occurs is very obvious. Hence the Session.execute() method now becomes the
> place where users have to "yield". With the older Query interface, the
> "yields" would be all over the place and kind of arbirary, since some Query
> methods decide to execute at one point or another.
>
> Flask-SQLAlchemy therefore has to decide where it wants to go with this
> direction, and there are options, including sticking with the legacy query
> / dynamic loader, perhaps vendoring a new interface that behaves in the
> flask-sqlalchemy style but uses 2.0-style patterns under the hood, or it
> can go along with the 2.0 model for future releases. From
> SQLAlchemy's point of view, the Query was always not well thought out and
> was inconsistent with how Core worked, and I've wanted for years to resolve
> that problem.
>
> - mike
>
>
>
>
> On Thursday, February 25, 2021 at 2:21:43 PM UTC-8 Mike Bayer wrote:
>
>
> this will be fixed in https://github.com/sqlalchemy/sqlalchemy/issues/5981
> where I've reverted entirely some changes to AppenderQuery that made it
> work more in 2.0 style. As Query is going to be present in 2.0, "dynamic"
> relationships will remain also as legacy. They are superseded by explicit
> use of the with_parent() filtering construct.
>
>
>
> On Thu, Feb 25, 2021, at 3:25 PM, Ahmed wrote:
>
> Hello,
>
> It seems that SQLAlchemy 1.4.0b3 ignores relationship() query_class
> parameter. Here's the snippet that works with 1.3 but doesn't with 1.4:
>
> class Parent(db.Model):
> __tablename__ = "todo"
> id = db.Column(db.Integer, primary_key=True)
> # ... Column mappings
> children = db.relationship("Child",
> backref="todo", query_class=DerivedQuery, lazy="dynamic")
>
> class Child(db.Model):
> __tablename__ = "todo"
> # ... Colum
Re: [sqlalchemy] relationship query_class in SQLAlchemy 1.4.0b3
On Fri, Feb 26, 2021, at 8:04 AM, Ahmed wrote: > Hi Mike - Thank you for your insights. Actually, this is part of upgrading > Flask-SQLAlchemy library dependency to 1.4.0b3 and eventually 2.0. The > snippet above is extracted from a test case that didn't pass against 1.4.0b3. > > I've checked sqlalchemy.orm.with_parent > <https://docs.sqlalchemy.org/en/14/orm/query.html?highlight=with_parent#sqlalchemy.orm.with_parent> > (Python function, in Query API) documentation entry, however, it's not clear > to me how with_parent construct can fit in the implementation instead of > Query. I guess it would require a major change in how the library > (Flask-SQLAlchemy) is currently designed as it functionally extends > sqlalchemy.orm.Query and pass the extended class to relationship and other > constructs as well. yes so, SQLAlchemy 2.0's approach is frankly at odds with the spirit of Flask-SQLAlchemy.The Query and "dynamic" loaders are staying around largely so that Flask can come on board, however the patterns in F-S are pretty much the ones I want to get away from. 2.0's spirit is one where the act of creating a SELECT statement is a standalone thing that is separate from being attached to any specific class (really all of SQLAlchemy was like this, but F-S has everyone doing the Model.query thing that I've always found to be more misleading than helpful), but SELECT statements are now also disconnected from any kind of "engine" or "Session" when constructed. as for with_parent(), with_parent is what the dynamic loader actually uses to create the query. so this is a matter of code organization. F-S would have you say: user = User.query.filter_by(name='name').first() address = user.addresses.filter_by(email='email').first() noting above, there's no "Session" anywhere. where is it? Here's a Hacker News comment lamenting the real world implications of this: https://news.ycombinator.com/item?id=26183936 SQLAlchemy 2.0 would have you say instead: with Session(engine) as session: user = session.execute( select(User).filter_by(name='name') ).scalars().first() address = session.execute( select(Address).where(with_parent(user, Address.user)).filter_by(email='email') ).scalars().first() Noting above, a web framework integration may still wish to provide the "session" to data-oriented methods and manage its scope, but IMO it should be an explicit object passed around. The database connection / transaction shouldn't be made to appear to be inside the ORM model object, since that's not what's actually going on. If you look at any commentary anywhere about SQLAlchemy, the top complaints are: 1. too magical, too implicit 2. what's wrong with just writing SQL? SQLAlchemy 2.0 seeks to streamline the act of ORMing such that the user *is* writing SQL, they're running it into an execute() method, and they are managing the scope of connectivity and transactions in an obvious way. People don't necessarily want bloat and verbosity but they do want to see explicitness when the computer is being told to do something, especially running a SQL query. We're trying to hit that balance as closely as possible. The above style also has in mind compatibility with asyncio, which we now support. With asyncio, it's very important that the boundary where IO occurs is very obvious. Hence the Session.execute() method now becomes the place where users have to "yield". With the older Query interface, the "yields" would be all over the place and kind of arbirary, since some Query methods decide to execute at one point or another. Flask-SQLAlchemy therefore has to decide where it wants to go with this direction, and there are options, including sticking with the legacy query / dynamic loader, perhaps vendoring a new interface that behaves in the flask-sqlalchemy style but uses 2.0-style patterns under the hood, or it can go along with the 2.0 model for future releases. From SQLAlchemy's point of view, the Query was always not well thought out and was inconsistent with how Core worked, and I've wanted for years to resolve that problem. - mike > On Thursday, February 25, 2021 at 2:21:43 PM UTC-8 Mike Bayer wrote: >> __ >> this will be fixed in https://github.com/sqlalchemy/sqlalchemy/issues/5981 >> where I've reverted entirely some changes to AppenderQuery that made it work >> more in 2.0 style. As Query is going to be present in 2.0, "dynamic" >> relationships will remain also as legacy. They are superseded by explicit >> use of the with_parent() filtering construct. >> >> >> >> On Thu, Feb 25, 2021, at 3:25 PM, Ahmed wrote: >>> Hello, >>> >>> It seems that SQLAlchemy 1.4.0b3 ignores relation
Re: [sqlalchemy] relationship query_class in SQLAlchemy 1.4.0b3
Hi Mike - Thank you for your insights. Actually, this is part of upgrading
Flask-SQLAlchemy library dependency to 1.4.0b3 and eventually 2.0. The
snippet above is extracted from a test case that didn't pass against
1.4.0b3.
I've checked sqlalchemy.orm.with_parent
<https://docs.sqlalchemy.org/en/14/orm/query.html?highlight=with_parent#sqlalchemy.orm.with_parent>
(Python
function, in Query API) documentation entry, however, it's not clear to me
how with_parent construct can fit in the implementation instead of Query. I
guess it would require a major change in how the library (Flask-SQLAlchemy)
is currently designed as it functionally extends sqlalchemy.orm.Query and
pass the extended class to relationship and other constructs as well.
On Thursday, February 25, 2021 at 2:21:43 PM UTC-8 Mike Bayer wrote:
> this will be fixed in https://github.com/sqlalchemy/sqlalchemy/issues/5981
> where I've reverted entirely some changes to AppenderQuery that made it
> work more in 2.0 style. As Query is going to be present in 2.0, "dynamic"
> relationships will remain also as legacy. They are superseded by explicit
> use of the with_parent() filtering construct.
>
>
>
> On Thu, Feb 25, 2021, at 3:25 PM, Ahmed wrote:
>
> Hello,
>
> It seems that SQLAlchemy 1.4.0b3 ignores relationship() query_class
> parameter. Here's the snippet that works with 1.3 but doesn't with 1.4:
>
> class Parent(db.Model):
> __tablename__ = "todo"
> id = db.Column(db.Integer, primary_key=True)
> # ... Column mappings
> children = db.relationship("Child",
> backref="todo", query_class=DerivedQuery, lazy="dynamic")
>
> class Child(db.Model):
> __tablename__ = "todo"
> # ... Column mappings
> parent_id = db.Column(db.Integer, db.ForeignKey("todo.id"))
>
> assert isinstance(p.children, DerivedQuery)
>
> In 1.4, children attribute is always an instance of AppenderQuery
> regardless of the query_class value. I might have missed something above
> though.
>
>
>
> --
> SQLAlchemy -
> The Python SQL Toolkit and Object Relational Mapper
>
> http://www.sqlalchemy.org/
>
> To post example code, please provide an MCVE: Minimal, Complete, and
> Verifiable Example. See http://stackoverflow.com/help/mcve for a full
> description.
> ---
> You received this message because you are subscribed to the Google Groups
> "sqlalchemy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sqlalchemy+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sqlalchemy/4454277c-b3a1-484e-b0e5-aef3e72eeb01n%40googlegroups.com
>
> <https://groups.google.com/d/msgid/sqlalchemy/4454277c-b3a1-484e-b0e5-aef3e72eeb01n%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
--
SQLAlchemy -
The Python SQL Toolkit and Object Relational Mapper
http://www.sqlalchemy.org/
To post example code, please provide an MCVE: Minimal, Complete, and Verifiable
Example. See http://stackoverflow.com/help/mcve for a full description.
---
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sqlalchemy/087934f8-d7fb-4062-8b2a-9d623a2e7941n%40googlegroups.com.
Re: [sqlalchemy] relationship query_class in SQLAlchemy 1.4.0b3
this will be fixed in https://github.com/sqlalchemy/sqlalchemy/issues/5981
where I've reverted entirely some changes to AppenderQuery that made it work
more in 2.0 style. As Query is going to be present in 2.0, "dynamic"
relationships will remain also as legacy. They are superseded by explicit use
of the with_parent() filtering construct.
On Thu, Feb 25, 2021, at 3:25 PM, Ahmed wrote:
> Hello,
>
> It seems that SQLAlchemy 1.4.0b3 ignores relationship() query_class
> parameter. Here's the snippet that works with 1.3 but doesn't with 1.4:
>
> class Parent(db.Model):
> __tablename__ = "todo"
> id = db.Column(db.Integer, primary_key=True)
> # ... Column mappings
> children = db.relationship("Child", backref="todo",
> query_class=DerivedQuery, lazy="dynamic")
>
> class Child(db.Model):
> __tablename__ = "todo"
> # ... Column mappings
> parent_id = db.Column(db.Integer, db.ForeignKey("todo.id"))
>
> assert isinstance(p.children, DerivedQuery)
>
> In 1.4, children attribute is always an instance of AppenderQuery regardless
> of the query_class value. I might have missed something above though.
>
>
>
> --
> SQLAlchemy -
> The Python SQL Toolkit and Object Relational Mapper
>
> http://www.sqlalchemy.org/
>
> To post example code, please provide an MCVE: Minimal, Complete, and
> Verifiable Example. See http://stackoverflow.com/help/mcve for a full
> description.
> ---
> You received this message because you are subscribed to the Google Groups
> "sqlalchemy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sqlalchemy+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sqlalchemy/4454277c-b3a1-484e-b0e5-aef3e72eeb01n%40googlegroups.com
>
> <https://groups.google.com/d/msgid/sqlalchemy/4454277c-b3a1-484e-b0e5-aef3e72eeb01n%40googlegroups.com?utm_medium=email_source=footer>.
--
SQLAlchemy -
The Python SQL Toolkit and Object Relational Mapper
http://www.sqlalchemy.org/
To post example code, please provide an MCVE: Minimal, Complete, and Verifiable
Example. See http://stackoverflow.com/help/mcve for a full description.
---
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sqlalchemy/38ad4e7a-cf4d-4688-b21b-e35c60d98a62%40www.fastmail.com.
Re: [sqlalchemy] relationship query_class in SQLAlchemy 1.4.0b3
this is a bug. however, the Query object is legacy. what is your actual use
case? there are better ways to achieve them now.
On Thu, Feb 25, 2021, at 3:25 PM, Ahmed wrote:
> Hello,
>
> It seems that SQLAlchemy 1.4.0b3 ignores relationship() query_class
> parameter. Here's the snippet that works with 1.3 but doesn't with 1.4:
>
> class Parent(db.Model):
> __tablename__ = "todo"
> id = db.Column(db.Integer, primary_key=True)
> # ... Column mappings
> children = db.relationship("Child", backref="todo",
> query_class=DerivedQuery, lazy="dynamic")
>
> class Child(db.Model):
> __tablename__ = "todo"
> # ... Column mappings
> parent_id = db.Column(db.Integer, db.ForeignKey("todo.id"))
>
> assert isinstance(p.children, DerivedQuery)
>
> In 1.4, children attribute is always an instance of AppenderQuery regardless
> of the query_class value. I might have missed something above though.
>
>
>
> --
> SQLAlchemy -
> The Python SQL Toolkit and Object Relational Mapper
>
> http://www.sqlalchemy.org/
>
> To post example code, please provide an MCVE: Minimal, Complete, and
> Verifiable Example. See http://stackoverflow.com/help/mcve for a full
> description.
> ---
> You received this message because you are subscribed to the Google Groups
> "sqlalchemy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sqlalchemy+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sqlalchemy/4454277c-b3a1-484e-b0e5-aef3e72eeb01n%40googlegroups.com
>
> <https://groups.google.com/d/msgid/sqlalchemy/4454277c-b3a1-484e-b0e5-aef3e72eeb01n%40googlegroups.com?utm_medium=email_source=footer>.
--
SQLAlchemy -
The Python SQL Toolkit and Object Relational Mapper
http://www.sqlalchemy.org/
To post example code, please provide an MCVE: Minimal, Complete, and Verifiable
Example. See http://stackoverflow.com/help/mcve for a full description.
---
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sqlalchemy/03df1372-8aa8-4189-b74f-e01c43859fd2%40www.fastmail.com.
[sqlalchemy] relationship query_class in SQLAlchemy 1.4.0b3
Hello,
It seems that SQLAlchemy 1.4.0b3 ignores relationship() query_class
parameter. Here's the snippet that works with 1.3 but doesn't with 1.4:
class Parent(db.Model):
__tablename__ = "todo"
id = db.Column(db.Integer, primary_key=True)
# ... Column mappings
children = db.relationship("Child",
backref="todo", query_class=DerivedQuery, lazy="dynamic")
class Child(db.Model):
__tablename__ = "todo"
# ... Column mappings
parent_id = db.Column(db.Integer, db.ForeignKey("todo.id"))
assert isinstance(p.children, DerivedQuery)
In 1.4, children attribute is always an instance of AppenderQuery
regardless of the query_class value. I might have missed something above
though.
--
SQLAlchemy -
The Python SQL Toolkit and Object Relational Mapper
http://www.sqlalchemy.org/
To post example code, please provide an MCVE: Minimal, Complete, and Verifiable
Example. See http://stackoverflow.com/help/mcve for a full description.
---
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sqlalchemy/4454277c-b3a1-484e-b0e5-aef3e72eeb01n%40googlegroups.com.
