Release notes
*Sourced from [sqlalchemy's releases](https://github.com/sqlalchemy/sqlalchemy/releases).*
>
> # 1.3.12
>
> Released: December 16, 2019
> ## orm
>
>
> - **[orm] [bug]** Fixed issue involving `lazy="raise"` strategy where an ORM delete of an
> object would raise for a simple "use-get" style many-to-one relationship
> that had lazy="raise" configured. This is inconsistent vs. the change
> introduced in 1.3 as part of [#4353](http://www.sqlalchemy.org/trac/ticket/4353), where it was established that
> a history operation that does not expect emit SQL should bypass the
> `lazy="raise"` check, and instead effectively treat it as
> `lazy="raise_on_sql"` for this case. The fix adjusts the lazy loader
> strategy to not raise for the case where the lazy load was instructed that
> it should not emit SQL if the object were not present.
>
> References: [#4997](http://www.sqlalchemy.org/trac/ticket/4997)
>
> - **[orm] [bug]** Fixed regression introduced in 1.3.0 related to the association proxy
> refactor in [#4351](http://www.sqlalchemy.org/trac/ticket/4351) that prevented `composite()` attributes
> from working in terms of an association proxy that references them.
>
> References: [#5000](http://www.sqlalchemy.org/trac/ticket/5000)
>
> - **[orm] [bug]** Setting persistence-related flags on `relationship()` while also
> setting viewonly=True will now emit a regular warning, as these flags do
> not make sense for a viewonly=True relationship. In particular, the
> "cascade" settings have their own warning that is generated based on the
> individual values, such as "delete, delete-orphan", that should not apply
> to a viewonly relationship. Note however that in the case of "cascade",
> these settings are still erroneously taking effect even though the
> relationship is set up as "viewonly". In 1.4, all persistence-related
> cascade settings will be disallowed on a viewonly=True relationship in
> order to resolve this issue.
>
> References: [#4993](http://www.sqlalchemy.org/trac/ticket/4993)
>
> - **[orm] [bug] [py3k]** Fixed issue where when assigning a collection to itself as a slice, the
> mutation operation would fail as it would first erase the assigned
> collection inadvertently. As an assignment that does not change the
> contents should not generate events, the operation is now a no-op. Note
> that the fix only applies to Python 3; in Python 2, the `__setitem__`
> hook isn't called in this case; `__setslice__` is used instead which
> recreates the list item-by-item in all cases.
>
> References: [#4990](http://www.sqlalchemy.org/trac/ticket/4990)
>
> - **[orm] [bug]** Fixed issue where by if the "begin" of a transaction failed at the Core
> engine/connection level, such as due to network error or database is locked
> ... (truncated)
Commits
- See full diff in [compare view](https://github.com/sqlalchemy/sqlalchemy/commits)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language
- `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language
- `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language
- `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme
Additionally, you can set the following in your Dependabot [dashboard](https://app.dependabot.com):
- Update frequency (including time of day and day of week)
- Pull request limits (per update run and/or open at any time)
- Out-of-range updates (receive only lockfile updates, if desired)
- Security updates (receive only security updates, if desired)
Bumps sqlalchemy from 1.3.11 to 1.3.12.
Release notes
*Sourced from [sqlalchemy's releases](https://github.com/sqlalchemy/sqlalchemy/releases).* > > # 1.3.12 > > Released: December 16, 2019 > ## orm > > > - **[orm] [bug]** Fixed issue involving `lazy="raise"` strategy where an ORM delete of an > object would raise for a simple "use-get" style many-to-one relationship > that had lazy="raise" configured. This is inconsistent vs. the change > introduced in 1.3 as part of [#4353](http://www.sqlalchemy.org/trac/ticket/4353), where it was established that > a history operation that does not expect emit SQL should bypass the > `lazy="raise"` check, and instead effectively treat it as > `lazy="raise_on_sql"` for this case. The fix adjusts the lazy loader > strategy to not raise for the case where the lazy load was instructed that > it should not emit SQL if the object were not present. > > References: [#4997](http://www.sqlalchemy.org/trac/ticket/4997) > > - **[orm] [bug]** Fixed regression introduced in 1.3.0 related to the association proxy > refactor in [#4351](http://www.sqlalchemy.org/trac/ticket/4351) that prevented `composite()` attributes > from working in terms of an association proxy that references them. > > References: [#5000](http://www.sqlalchemy.org/trac/ticket/5000) > > - **[orm] [bug]** Setting persistence-related flags on `relationship()` while also > setting viewonly=True will now emit a regular warning, as these flags do > not make sense for a viewonly=True relationship. In particular, the > "cascade" settings have their own warning that is generated based on the > individual values, such as "delete, delete-orphan", that should not apply > to a viewonly relationship. Note however that in the case of "cascade", > these settings are still erroneously taking effect even though the > relationship is set up as "viewonly". In 1.4, all persistence-related > cascade settings will be disallowed on a viewonly=True relationship in > order to resolve this issue. > > References: [#4993](http://www.sqlalchemy.org/trac/ticket/4993) > > - **[orm] [bug] [py3k]** Fixed issue where when assigning a collection to itself as a slice, the > mutation operation would fail as it would first erase the assigned > collection inadvertently. As an assignment that does not change the > contents should not generate events, the operation is now a no-op. Note > that the fix only applies to Python 3; in Python 2, the `__setitem__` > hook isn't called in this case; `__setslice__` is used instead which > recreates the list item-by-item in all cases. > > References: [#4990](http://www.sqlalchemy.org/trac/ticket/4990) > > - **[orm] [bug]** Fixed issue where by if the "begin" of a transaction failed at the Core > engine/connection level, such as due to network error or database is locked > ... (truncated)Commits
- See full diff in [compare view](https://github.com/sqlalchemy/sqlalchemy/commits)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase
.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) - `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language - `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language - `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language - `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language - `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme Additionally, you can set the following in your Dependabot [dashboard](https://app.dependabot.com): - Update frequency (including time of day and day of week) - Pull request limits (per update run and/or open at any time) - Out-of-range updates (receive only lockfile updates, if desired) - Security updates (receive only security updates, if desired)