Closed (won't fix)
Project:
Drupal core
Version:
8.9.x-dev
Component:
database system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
1 May 2017 at 13:02 UTC
Updated:
28 Mar 2020 at 09:42 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
mondrakeTest only patch to demonstrate the issue. It just forces all the core drivers to not support transactions.
Comment #4
mondrakeAt least the TransactionTest failures seem related to test code not checking if transaction support is enabled.
The patches here:
Comment #6
mondrakeI cannot find anywhere code that would add an 'Explicit rollback failed' message to the watchdog, which is checked in the BlockContentCreationTest and NodeCreationTest. Is that just dead code that by setting the driver not to support transactions lives back again?
The PostgresSql failure seems a different problem.
Comment #7
mondrakeReroll.
Comment #11
mondrakeReroll
Comment #12
mondrakeComment #16
mondrakeComment #17
daffie commentedI have just one remark. The rest of the patch is RTBC for me.
Is it possible that the rollback failure is logged under some other name then what the test is now locking for?
Comment #18
daffie commentedComment #19
daffie commented@mondrake: Do you know if we have a database driver without transaction support in core? If not is it possible to add testing for that?
Comment #20
mondrakeThe patch is rather outdated ATM, would certainly need a reroll to start with.
However, more in general:
a) I think all core drivers are set to support transactions, currently (SQLite coming last to the club) so: core de-facto requires transactional db operations
b) in 2020, even in contribland, will there be db platforms NOT supporting transactions?
So - wouldn't it be better to deprecate/remove support for non-transactional db operations instead?
Comment #21
mondrake#19 my bad, it seems the last one to join the transactional club in Drupal was MySql when MyISAM was dropped: https://www.drupal.org/node/2278745. Not SQLite then.
Interestingly, from the CR:
and also #2275535: [policy, no patch] Drop support for non-transactional database engines (including MyISAM), #2278971: Deprecate Connection::supportsTransactions().
Apparently, we never got to the bottom of eradicating non-transactional support...
Comment #22
daffie commentedI am working on creating a database driver for MongoDB and they do transactions. It is implemented differently then SQL databases. So I would like to have the option of disabling the SQL type transactions.
Comment #23
mondrake@daffie you probably want to bypass SQL backends to store data, but in this issue we're only talking about SQL databases and their support (or not) of transactional integrity, i.e. when multiple database operations need to be managed as a single commit to the db or rolled back if any of the suboperation fails. Just to say the two things seem independent from each other, to me.
Comment #24
mondrakeI have revived #2278971: Deprecate Connection::supportsTransactions(), adding a patch there, and am inclined to close this one as a won't fix, but leaving open ATM for any comment.
Comment #25
mondrake#2275535: [policy, no patch] Drop support for non-transactional database engines (including MyISAM) set the policy for must have transaction support, and #2278971: Deprecate Connection::supportsTransactions() is going to enforce that, so this issue becomes redundant.