Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump sqlalchemy from 2.0.17 to 2.0.19 #344

Merged
merged 1 commit into from
Aug 3, 2023

Conversation

dependabot[bot]
Copy link

@dependabot dependabot bot commented on behalf of github Aug 1, 2023

Bumps sqlalchemy from 2.0.17 to 2.0.19.

Release notes

Sourced from sqlalchemy's releases.

2.0.19

Released: July 15, 2023

orm

  • [orm] [bug] Fixed issue where setting a relationship collection directly, where an object in the new collection were already present, would not trigger a cascade event for that object, leading to it not being added to the _orm.Session if it were not already present. This is similar in nature to #6471 and is a more apparent issue due to the removal of cascade_backrefs in the 2.0 series. The _orm.AttributeEvents.append_wo_mutation() event added as part of #6471 is now also emitted for existing members of a collection that are present in a bulk set of that same collection.

    References: #10089

  • [orm] [bug] Fixed issue where objects that were associated with an unloaded collection via backref, but were not merged into the _orm.Session due to the removal of cascade_backrefs in the 2.0 series, would not emit a warning that these objects were not being included in a flush, even though they were pending members of the collection; in other such cases, a warning is emitted when a collection being flushed contains non-attached objects which will be essentially discarded. The addition of the warning for backref-pending collection members establishes greater consistency with collections that may be present or non-present and possibly flushed or not flushed at different times based on different relationship loading strategies.

    References: #10090

  • [orm] [bug] [regression] Fixed additional regression caused by #9805 where more aggressive propagation of the "ORM" flag on statements could lead to an internal attribute error when embedding an ORM Query construct that nonetheless contained no ORM entities within a Core SQL statement, in this case ORM-enabled UPDATE and DELETE statements.

    References: #10098

engine

  • [engine] [bug] Renamed _result.Row.t and _result.Row.tuple() to _result.Row._t and _result.Row._tuple(); this is to suit the policy that all methods and pre-defined attributes on Row should be in the style of Python standard library namedtuple where all fixed names have a leading underscore, to avoid name conflicts with existing column names. The previous method/attribute is now deprecated and will

... (truncated)

Commits

Dependabot compatibility score

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 dependabot bot requested a review from a team as a code owner August 1, 2023 15:32
@dependabot dependabot bot added dependency Dependency upgrades pip Python dependency changes labels Aug 1, 2023
@sea-kelp
Copy link
Collaborator

sea-kelp commented Aug 2, 2023

Tested with 2.0.18, which ran fine. Something in 2.0.19 seems to be breaking the build 😭
sqlalchemy/sqlalchemy@rel_2_0_18...rel_2_0_19

@sea-kelp
Copy link
Collaborator

sea-kelp commented Aug 2, 2023

When updating an Incident, it seems to be trying to re-add a duplicate row for each officer in the officers field to the officer_incidents table, violating the PK constraint on both table columns. I took a quick look through the commits in the new release and none of them look relevant

@sea-kelp sea-kelp mentioned this pull request Aug 2, 2023
3 tasks
@sea-kelp
Copy link
Collaborator

sea-kelp commented Aug 2, 2023

@dependabot rebase

Bumps [sqlalchemy](https://github.com/sqlalchemy/sqlalchemy) from 2.0.17 to 2.0.19.
- [Release notes](https://github.com/sqlalchemy/sqlalchemy/releases)
- [Changelog](https://github.com/sqlalchemy/sqlalchemy/blob/main/CHANGES.rst)
- [Commits](https://github.com/sqlalchemy/sqlalchemy/commits)

---
updated-dependencies:
- dependency-name: sqlalchemy
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <[email protected]>
@dependabot dependabot bot force-pushed the dependabot/pip/sqlalchemy-2.0.19 branch from 030075f to 656f816 Compare August 2, 2023 21:41
@sea-kelp sea-kelp merged commit bb4dbc5 into main Aug 3, 2023
2 checks passed
@sea-kelp sea-kelp deleted the dependabot/pip/sqlalchemy-2.0.19 branch August 3, 2023 09:01
michplunkett pushed a commit to lucyparsons/OpenOversight that referenced this pull request Aug 3, 2023
## Description of Changes
Merging fix OrcaCollective#347
upstream.

**Original PR description**:
Only add new officers to incidents.

When a user edits an incident currently, we retrieve the Incident from
the database and append all officers in the form to that Incident. This
led to sqlalchemy trying to insert duplicate rows into the
officer_incidents association table.

As far as I can tell, this was silently ignored by sqlalchemy in the
past and no unexpected rows were created. With the upgrade to sqlalchemy
2.0.19 (OrcaCollective#344), the
library appears to have started raising exceptions related to this
behavior.

This change checks to see whether an officer already exists in
Incident.officers before adding them so as to not add duplicate
officers.

## Notes for Deployment
N/A

## Screenshots (if appropriate)
N/A

## Tests and linting
 - [x] This branch is up-to-date with the `develop` branch.
 - [x] `pytest` passes on my local development environment.
 - [x] `pre-commit` passes on my local development environment.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependency Dependency upgrades pip Python dependency changes
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

1 participant