Opened 8 years ago
Closed 8 years ago
#27677 closed New feature (wontfix)
Disable savepoint support for MySQL NDB engine tables, and option to overwrite the default.
Reported by: | Alan Justino da Silva | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Adam Johnson | Triage Stage: | Unreviewed |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | no |
Description
Savepoint support for MySQL has introduced in ~2012. Right now there is the NDBCLUSTER engine that does support transactions but does not support savepoints. And returns error if tried.
(Related: #15507)
On Github PR https://github.com/django/django/pull/7779 is code that disables savepoints for NDB/NDBCLUSTER but allows user to explicitly enable/disable savepoints for this and other engines in the future if needed.
Please provide feedback before effort be put in documentation on this new feature.
Change History (4)
comment:1 by , 8 years ago
Cc: | added |
---|
follow-up: 3 comment:2 by , 8 years ago
I'm unsure to what lengths Django should go to support alternate storage engines
NDB isn't just a storage engine - you need to use a different version of MySQL (from Oracle) to use it. Also NDB cluster is just one of many clustering database options for MySQL, some others being:
- Percona XtraDB Cluster (XtraDB = InnoDB, should be less different)
- MariaDB Galera Cluster (Also uses XtraDB / InnoDB)
I'm afraid I don't have any experience with NDB, or any of the above. I suspect there will be more issues rather than just the lack of savepoints; e.g. the docs include a table of differences between the NDB and InnoDB storage engines with many entries, and this isn't even where the lack of savepoints is documented. Some suspicious entries I saw at a glance: only READ-COMMITTED transaction isolation (pertinent to #27683) and the difference in data types with 'large row support'.
I'd suggest for the time making and testing a third party database backend that overrides uses_savepoints
(etc.), rather than changing Django core directly right now, since we can't test it, and it doesn't seem that popular.
comment:3 by , 8 years ago
Replying to Adam Chainz:
I'm unsure to what lengths Django should go to support alternate storage engines
I guess it is ok to just not disallow their use
I'd suggest for the time making and testing a third party database backend that overrides
uses_savepoints
(etc.), rather than changing Django core directly right now, since we can't test it, and it doesn't seem that popular.
Will it be better if the patch just allows the feature to be disabled, with no explicit effort to detect the engine used? It would be enough for now.
comment:4 by , 8 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
As Adam suggested, you can disable savepoints without patching Django by writing a custom database backend. This has the benefit that you won't need to wait several months until the next version of Django is released. If you find you need other database backend hooks that Django doesn't provide, feel free to let us know.
I'm unsure to what lengths Django should go to support alternate storage engines. I'm not sure if it's possible to test NDB on our continuous integration infrastructure, for example.
Adam, do you have any input?