Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
abstract class DrupalSqlBase
is the base class for nearly every@MigrateSource
plugin.\Drupal\migrate_drupal\Plugin\migrate\source\DrupalSqlBase::checkRequirements()
calls\Drupal\migrate_drupal\Plugin\migrate\source\DrupalSqlBase::moduleExists()
, which calls\Drupal\migrate_drupal\Plugin\migrate\source\DrupalSqlBase::getSystemData()
, which does a DB query to collect all data in the Drupal 6/7system
DB table and statically caches the result
The consequence is that the system
table is usually queried over a hundred times. Even though the system
table of the source site of course always stays the same, regardless of the source plugin used.
Proposed resolution
Reduce this to a single query without breaking BC, to improve performance.
Remaining tasks
None.
User interface changes
None.
API changes
None.
Data model changes
None.
Release notes snippet
None.
Comment | File | Size | Author |
---|---|---|---|
#12 | 3154156-12.patch | 1.63 KB | Wim Leers |
#12 | interdiff.txt | 685 bytes | Wim Leers |
#2 | 3154156-2.patch | 1.83 KB | Wim Leers |
Comments
Comment #2
Wim LeersComment #3
Wim LeersCalling
checkRequirements()
on every (derived) migration plugin instances with\Drupal\migrate_drupal\MigrationPluginManager
's cache primed (meaning they've already been discovered), on the concrete project I'm working on:Comment #4
Wim Leers😅
Comment #5
quietone CreditAttribution: quietone as a volunteer commentedNice improvement that will help most migrations.
Ah, but source plugins that extend SqlBase can set a database connection. There is no guarantee that all source plugins will use the same db.
Comment #7
Wim Leers#5: But … this is specifically
DrupalSqlBase
, notSqlBase
. So only Drupal-DB-targeting source plugins will be affected by this. Which also means only they would get this performance improvement, and hence your concern in #5 would not apply?Perhaps you want to change the wording of the comment from "all source plugins" to something more specific? 🤓
Comment #8
quietone CreditAttribution: quietone as a volunteer commentedYes, a change to the comment would be good. Unfortunately, I am not coming up with anything (a bit late here). Also, the use of 'cross-instance' muddles things. I keep wondering if what I am thinking as 'cross-instance' is the same as yours. Perhaps the comments would be clearer without that.
Why deprecate this?
Comment #10
quietone CreditAttribution: quietone as a volunteer commentedTook another look and this will need proper deprecation of the property, https://www.drupal.org/node/2856615#how-param.
Comment #11
RoSk0Tested patch from #2 on 9.2.9. Call to
drush migrate:status --tag=tag -vvv
Speaks for itself.
With regards to
$systemData
property: maybe we should mark it internal instead?Comment #12
Wim Leers#11: Thanks for the test! 🥳
#10: The docs you linked to only work for method parameters, not for class properties. I don't think we can trigger a deprecation error for properties… I'm also fine with not deprecating this; there's no real cost in maintaining it anyway. Did that in this reroll.
Comment #14
Wim LeersThis failed because
\Drupal\Tests\migrate_drupal\Unit\source\DrupalSqlBaseTest::testMinimumVersion()
was newly introduced in #3151732: DrupalSqlBase::checkRequirements should test version with $minimum_version and is the only code violating the assumptions this patch introduces: it pretends there are different databases for each migration plugin definition.This is not reproducible in real-world scenarios. Therefore we should change that test.
Do you agree, @quietone?
Comment #16
Anybody@quietone here's an open question from @Wim Leers in #14, which might be relevant for the next steps here.
Still relevant for migration performance, updating version.