Warning about using backref with viewonly - how to make a two-way read-only relation?

[Tony Hignett]

Hi,

I'm trying to upgrade from 1.2.2 to 1.3.15 and a number of our relations have started generating these warnings:

```

SAWarning: Setting backref / back_populates on relationship <child.parent> to refer to viewonly relationship <parent.children> will be deprecated in SQLAlchemy 1.4, and will be disallowed in a future release.  viewonly relationships should not be mutated (this warning may be suppressed after 10 occurrences)

  (self, other),

```

I've read some of the related issues, e.g. https://github.com/sqlalchemy/sqlalchemy/issues/5149, https://github.com/sqlalchemy/sqlalchemy/issues/4993, but I don't understand how backref comes into it. We don't want to mutate anything along the backref.

Is there a way of expressing a two-way read-only relation?

The code looks like

```

class Parent(Base):

    pass

class Child1(Base):

    

    @declared_attr

    def parent(cls):

        return orm.relationship(

            Parent,

            ...,

            viewonly=True,

            backref="children1"

        )

class Child2(Base):

    [etc]

````

[Mike Bayer]

On Wed, Mar 18, 2020, at 11:22 AM, Tony Hignett wrote:

Hi,

I'm trying to upgrade from 1.2.2 to 1.3.15 and a number of our relations have started generating these warnings:

```

SAWarning: Setting backref / back_populates on relationship <child.parent> to refer to viewonly relationship <parent.children> will be deprecated in SQLAlchemy 1.4, and will be disallowed in a future release.  viewonly relationships should not be mutated (this warning may be suppressed after 10 occurrences)

  (self, other),

```

I've read some of the related issues, e.g. https://github.com/sqlalchemy/sqlalchemy/issues/5149, https://github.com/sqlalchemy/sqlalchemy/issues/4993, but I don't understand how backref comes into it. We don't want to mutate anything along the backref.

Is there a way of expressing a two-way read-only relation?

you should remove the backref.   have the "viewonly" relationship stand alone by itself.

The code looks like

```

class Parent(Base):

    pass

class Child1(Base):

    

    @declared_attr

    def parent(cls):

        return orm.relationship(

            Parent,

            ...,

            viewonly=True,

            backref="children1"

        )

class Child2(Base):

    [etc]

````

--

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/660cedf0-7066-42fe-93bc-d6e4d223b05c%40googlegroups.com.

[Mike Bayer]

On Wed, Mar 18, 2020, at 11:42 AM, Mike Bayer wrote:

On Wed, Mar 18, 2020, at 11:22 AM, Tony Hignett wrote:

Hi,

I'm trying to upgrade from 1.2.2 to 1.3.15 and a number of our relations have started generating these warnings:

```

SAWarning: Setting backref / back_populates on relationship <child.parent> to refer to viewonly relationship <parent.children> will be deprecated in SQLAlchemy 1.4, and will be disallowed in a future release.  viewonly relationships should not be mutated (this warning may be suppressed after 10 occurrences)

  (self, other),

```

I've read some of the related issues, e.g. https://github.com/sqlalchemy/sqlalchemy/issues/5149, https://github.com/sqlalchemy/sqlalchemy/issues/4993, but I don't understand how backref comes into it. We don't want to mutate anything along the backref.

Is there a way of expressing a two-way read-only relation?

you should remove the backref.   have the "viewonly" relationship stand alone by itself.

also if you want 'children1' to also be a viewonly relationship, set that up separately.

To view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy/40c0410d-0233-4abc-aae7-bfe728495647%40www.fastmail.com.

[Jonathan Vanasco]

Tony,

Mike helped me with a similar problem a few weeks ago:

https://groups.google.com/d/msg/sqlalchemy/k4a-v2ebeJM/bj73xd4CFwAJ

In his suggestion, I stash some mapper configuration data into `info`, then use the `mapper_configured` event to audit my configuration requirements.