INTPYTHON-355 Add transaction support

[timgraham]

(initial comments at #313)

The transactions tests are running via test-python-atlas.yml which uses https://hub.docker.com/r/mongodb/mongodb-atlas-local. I guess it uses a replica set.

Results from testing on a sharded cluster are in my comment below.

fixes #7

[aclark4life]

LGTM, thanks! I'll follow up with @blink1073 to discuss running the entire Django test suite on a sharded cluster.

[blink1073]

Yeah, the docker image only supports replica sets as I understand it. We maintain a GitHub Action that can start whatever you like, provided you don't need Atlas Search (which requires the docker container):

https://github.com/mongodb-labs/drivers-evergreen-tools/blob/master/action.yml
https://github.com/mongodb-labs/drivers-evergreen-tools/tree/master?tab=readme-ov-file#using-with-github-actions

You'd set toplogy: sharded_cluster

[timgraham]

Results from sharded cluster tests:

1. I've seen some a couple transient failures of the form:

Transaction fc444a97-2534-4c44-9ee3-cba40a215038 - Il1bctjvfYRA0JpLUY4Xle2E6bw+KM1YpMr4x52qGgE= - - :2767 was aborted on statement 8 due to: an error from cluster data placement change :: caused by :: PlanExecutor error during aggregation :: caused by :: Routing info refresh did not complete

Someone will have to interpret the meaning.

2. It seems there's a problem using a dummy collection.

MongoDB errors with "sharding status of collection test_djangotests.__null is not currently known and needs to be recovered".

[WaVEV]

LGTM

[aclark4life]

Via @timgraham , in case we need to revert

does the separate atomic function look like the to-be-reverted transactions PR

Yes, the logic should be pretty similar, I think. It might take a week of adjustments to collect the relevant tests from Django's test suite, adjust the method names not to collide with Django's APIs, and update the documentation. The biggest loss IMO, is that the running tests is quite a bit slower without using a transaction to speed them up. … Besides monkeypatching django.test.TestCase, I suppose there's the possibility of providing a TestCase subclass that uses MongoDB's atomic instead of Django's. I'm not sure if it's worth it... it might be a bit complicated (e.g. multi-db considerations) and a down the road possibility, I think.