Jonyscathe/execute mutate

[jonyscathe]

This adds support for modifying mock_data through any of:

session.execute(insert(my_table).values(<list of dicts to insert>))  # similar to session.add()
session.execute(insert(my_table), <list of dicts to insert>)  # similar to session.add()
session.execute(insert(my_table).returning(my_table), <list of dicts to insert>).scalar()  # similar to session.add(), in theory should return ORM object, in practice, don't quite have that one working yet... Not terribly simple to do, and not needed in my project.
session.execute(update(my_table).where(<some expression).values(<dict of values to update>))  # Will update data in self._mock_data as appropraite
session.execute(delete(my_table).where(<some expression))  # will delete data in self._mock_data as appropriate.

This allows for the mocking of ORM 2.0 style expressions .

Tests and documentation has not been updated yet, and I am not sure that this will not cause any runtime issues with sqlalchemy < 1.4.0.
I wanted to get feedback on this first before going to the effort to update tests/documentation/compatibility.

If you are happy with these changes then I'll update the tests/doco/etc.

Note: I currently have this working in a project that has 185 various session.execute() calls that previously had 185 various session.query() or session.add() calls. Mocking is working well, and the ability to actually update mocked data has been particularly useful as I wasn't able to do that previously.

[jonyscathe]

Any comments on whether or not this change is wanted?

It isn't a huge amount of work for me to get pre-commit passing, add tests, add documentation. But don't want to spend my time doing that if you aren't ok with the change itself.

[rajivsarvepalli]

Thanks for the pull-request to add this feature.

One overall comment would be to add unit testing so that we can verify these changes and then we can collaborate on a separate PR to enhance documentation for this feature so that users can leverage this new feature.

Have you noticed any regression issues with these changes? It appears the current unit tests are passing so it looks these changes should function fine for existing users,

[rajivsarvepalli]

Is there an opportunity here to break to down this new logic into a new function?

[rajivsarvepalli]

For ArgumentError shouldn't we inform the user that the mocked table could not be selected?

For TypeError , can we write this logic to a statement that is supported by multiple SqlAlchemy versions or do a check to verify the version supports executing select(table) statements rather relying on a exception to catch this case?

[rajivsarvepalli]

[FMI] Why is mutate and unify? Shouldn't this be mutate or unify?

Also do we need execute to be part of mutate as well?

[jonyscathe]

Good point.
Execute should just be its own special case. Which can mutate data and potentially unify depending on what is being executed.

[jonyscathe]

Thanks for the pull-request to add this feature.

One overall comment would be to add unit testing so that we can verify these changes and then we can collaborate on a separate PR to enhance documentation for this feature so that users can leverage this new feature.

Have you noticed any regression issues with these changes? It appears the current unit tests are passing so it looks these changes should function fine for existing users,

Added unit tests. Now back to 100% test coverage and pre-commit passing.
For tests I took test_mocking.py and made a similar file test_mocking_orm2.py and changed the code over to orm2 style and removed anything that was irrelevant or not supported.

I haven't added any support for session.get() or session.scalars(). See https://docs.sqlalchemy.org/en/20/changelog/migration_20.html#migration-orm-usage for info.
scalars() would be fairly easy to add. get() would be harder as we would need to distinguish between something like session.query(User).get(42) and something like session.get(User, 42) which should both give the same result, but are quite different syntax.

For an insert that returns data, currently I have it returning all data for that table rather than what was just inserted... So technically it isn't quite right. Still thinking about how to make it only return the row(s) inserted in that instruction.