Problem/Motivation
This builds upon #3190815: Source count caching broken: impossible to enable source count caching for SqlBase-based source plugins (plus, unneeded cache I/O) to fix the caching of the source count.
Source plugins that need to calculate the count of rows are overriding SourcePluginBase::count() which has the caching logic and that effectively prevents the use of the cache for the count of rows. The typical pattern is that there's extra work happening in ::initializeIterator()
, and hence ::count()
is overridden too. And because of crucial bugs in SourcePluginBase::count()
and especially SqlBase::count()
, people have been forced to override ::count()
.
The relevant code is in \Drupal\migrate\Plugin\migrate\source\SourcePluginBase::count()
+ \Drupal\migrate\Plugin\migrate\source\SourcePluginBase::$cacheCounts
.
Therefore, once #3190815: Source count caching broken: impossible to enable source count caching for SqlBase-based source plugins (plus, unneeded cache I/O) is fixed, we'll be able to land this too, as will many contrib modules. For example: #3190804: Allow source counts to be cached: implement ::doCount() instead of ::count() and #3190800: Allow source counts to be cached: implement ::doCount() instead of ::count().
Steps to reproduce
Proposed resolution
Change any source plugins overriding \Drupal\migrate\Plugin\migrate\source\SourcePluginBase::count, which has the caching logic, to use \Drupal\migrate\Plugin\migrate\source\SqlBase::doCount instead.
The exception is EmbeddedDataSource.
Steps to reproduce
Proposed resolution
Change any source plugins overriding \Drupal\migrate\Plugin\migrate\source\SourcePluginBase::count, which has the caching logic, to use \Drupal\migrate\Plugin\migrate\source\SqlBase::doCount instead.
The exception is EmbeddedDataSource.
Remaining tasks
Review change record and the updated IS
Commit and smile.
User interface changes
N/A
API changes
N/A
Data model changes
N/A
Release notes snippet
N/A
Comment | File | Size | Author |
---|---|---|---|
#14 | interdiff_11-14.txt | 804 bytes | narendraR |
#14 | 3190818-14.patch | 6.39 KB | narendraR |
#12 | interdiff_7-11.txt | 599 bytes | narendraR |
#11 | 3190818-11.patch | 6.27 KB | narendraR |
#7 | 3190818-7.patch | 6.16 KB | Wim Leers |
Comments
Comment #2
Wim LeersThe typical pattern is that there's extra work happening in
::initializeIterator()
, and hence::count()
is overridden too.Because of crucial bugs in
SourcePluginBase::count()
and especiallySqlBase::count()
, people have been forced to override::count()
instead of::doCount()
.Therefore, once #3190815: Source count caching broken: impossible to enable source count caching for SqlBase-based source plugins (plus, unneeded cache I/O) is fixed, we'll be able to land this too, as will many contrib modules. For example: #3190804: Allow source counts to be cached: implement ::doCount() instead of ::count() and #3190800: Allow source counts to be cached: implement ::doCount() instead of ::count().
Comment #3
Wim LeersNit: should be
protected
.Comment #5
Wim Leers#3190815: Source count caching broken: impossible to enable source count caching for SqlBase-based source plugins (plus, unneeded cache I/O) landed! 🥳
Addressed #3.
Comment #7
Wim LeersLooks like #3 which I fixed in #5 wasn't the only one! 🙈
Comment #9
Wim LeersWell that is an interesting test failure:
Re-testing…
Comment #10
Wim LeersI have not yet been able to figure out what exactly in
\MigrationSourceCacheTest::testCacheCountsNotContaminated()
is causing the memory leak, but it sure smells like an infinite recursion problem 🤔Comment #11
narendraRComment #12
narendraRInterdiff
Comment #13
Wim LeersWow, great catch! Infinite recursion 🙈
Instead of this, let's do
i.e. let's not add
::doCount()
because it's dead code then.Let's instead update the existing
::count()
implementation and explain in a comment why it's implementing::count()
and not::doCount()
: to bypass caching. Its subclass is the one that is cacheable.Comment #14
narendraRThanks for the review. Here is the updated patch and interdiff file.
Comment #15
Wim Leers… and that's why this is the only example where we do not change
::count()
to::doCount()
!Comment #20
quietone CreditAttribution: quietone as a volunteer commentedComment #21
quietone CreditAttribution: quietone as a volunteer commentedWhile this clearly changes D6 and D7 source plugins I am not adding migrate-d6-d8 and am removing migrate-d7-d8. The original intention for those were for the Task migration issues for migrating database contents.
With the patch applied I grepped for 'function count' in source plugin directories. The latter two should not be changed, that is good. But why is ContentEntity not included. Oh, I see, it doesn't need to be. That method includes a call to the parent::count(). So that is right.
Yes, RTBC
Comment #22
benjifisherWhy is the testbot exercising the patch from #2?
I will trigger a re-test of the patch from #14.
Comment #23
quietone CreditAttribution: quietone as a volunteer commented@benjifisher. Yikes! I didn't even notice that last night when I updated the IS. Glad you caught it.
Comment #24
xjmCan we get a CR for this?
I'm also wondering about the disruption of just deleting all those public
count
implementations. I assume/hope that there is a parentcount()
implementation that any callers or child implementations would be using instead? Can we think of any potential disruptions to callers or child implementations from the logic being moved in this way?Thanks!
Comment #25
Wim Leers#24: Yes, exactly. They would all be inheriting
\Drupal\migrate\Plugin\migrate\source\SourcePluginBase::count()
.Comment #26
quietone CreditAttribution: quietone as a volunteer commentedUpdated the IS and the change record.
Comment #27
Wim LeersAwesome, thanks!
Comment #28
quietone CreditAttribution: quietone as a volunteer commentedYour welcome!
Woohoo!
Comment #29
alexpottCommitted 60f9243 and pushed to 9.3.x. Thanks!
As we've got a CR here going to commit to only 9.3.x. I think the BC / API implications of this change are minimal but better to take a more cautious path.