Hello, To be honest I’m pessimistic about the feasibility of emulating transactional behavior — pretty much the most complicated and low level thing databases do — in the application. I don’t think that would be considered suitable for Django.
Usually Django handles such cases with a database feature flag and make the methods no-ops on databases that don’t support the corresponding features. For instance that’s how Django ignores transactions on MySQL + MyISAM. Best regards, -- Aymeric. > On 2 Dec 2016, at 20:43, Mateusz Mikołajczyk <[email protected]> > wrote: > > Well, I suppose that it would either lead to very obfuscated implementation > code, or very weird syntax (client code). As for your first argument ( > promise that the transaction is unlikely to fail ): > > from django.db import distributed: > > with distributed('foo') as foo: > MyModel.get_or_create(field=123) > > then, before calling the emulated behavior, the db would have to: > > * do all the operations (like it would normally do with regular commit - thus > checking every constrainst and so on) > * then do a rollback (so that it doesn't store the actual values in the db) > * then serialize them in separate journal (the additional model I mentioned - > an analogy to an actual separate journal of PostgreSQL) > > Utterly ugly / hacky solution if you ask me, but please keep in mind that > this would be only emulation of the actual algorithm for the databases which > don't support this standart > > As for the relations, I have thought a lot about it and the only pseudocode I > could think of was utterly ugly as well: > > with distributed('foo') as foo: > foo.add(MyModel.objects.get_or_create, {'field': 123}, > namespace='mymodel') > foo.add(MyOtherModel.objects.create, {'my_model_id': ('from-namespace', > 'mymodel')}) > > Theoretically, both of these syntaxes could co-exist. If you wouldn't have > any relations, you could use the cleaner syntax. > > So I'd say it would technically be possible but would lead to very, very, > very ugly code (at least in the second scenario with relations). And I > realize that this is not an option in the Django world. > > I understand that because of all the above it is unlikely to create a nice > interface which would work in database-agnostic way, therefore Django would > have to throw IntegrityError if somebody would be trying to do distributed > transaction on non-supported database? But if that's the case then this code > doesn't really belong in the django core, does it? Which means that I'm > probably left with the monkey-patching thing :( Or .. ? I have to prepare > this functionality either way - because I need it ;) > > Thank you for all the answers ! > > W dniu piątek, 2 grudnia 2016 14:32:51 UTC+1 użytkownik Patryk Zawadzki > napisał: > W dniu piątek, 2 grudnia 2016 12:05:11 UTC+1 użytkownik Mateusz Mikołajczyk > napisał: > What would you say about checking which CRUD operations were executed within > atomic() call (in order to serialize them and save into a special model for > databases which don't support this functionality) ? Is it realistic? > > It would likely break the promise that distributed two-step transactions give > you: that once all statements are prepared the transaction is unlikely to > fail during commit. In this case the commit would mean "start over and try to > repeat my steps" at which point any of the recorded statements is likely to > fail constraint checks. (Even more so if your code used get_or_create().) > > Also how would relations work? You begin a transaction, create a Foo instance > and the returned PK is 5. You assign it to child models. At this point the > transaction is saved and rolled back. During replay the insert returns PK = > 7, at this point there's no way to detect that some of the stored fives > should now be treated as sevens while some should remain fives. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/django-developers > <https://groups.google.com/group/django-developers>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/8d4ca04f-cdcd-4d8b-a060-fc5598b3baf8%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/8d4ca04f-cdcd-4d8b-a060-fc5598b3baf8%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9FFC7815-C385-4C66-AED9-278D914F576A%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
