Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
migration system
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
10 Sep 2014 at 13:41 UTC
Updated:
23 Oct 2014 at 10:04 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
tstoecklerI had something like this.
Thoughts?
Comment #3
tstoecklerPretty please, Mrs. bot?!
Comment #4
benjy commentedYeah that looks good to me.
Comment #5
tstoecklerJust for the record: @dawehner showed me that you can in fact specify the
prefixpart of the database info as a per-table array, which would allow to solve the use-case described in the issue summary in the database layer instead of the migration system.It still makes sense to make this configurable, though, in my opinion. When sharing tables they might in fact reside in a different database alltogether, in which case this would be needed.
Comment #6
alexpottNeeds documentation somewhere - and unit tests?
Comment #7
tstoecklerI sort of agree on both points in theory, but neither do I know where to document things like this nor how to write proper tests.
For the documentation: This is really a feature of
SqlBase, but if we were to document it in that class I'm not sure how helpful that would be. I don't think many people look into that class. On the other hand this seems a little bit too specific for the general @migrate documentation overview.Regarding tests: Since we no longer have a
global $databasesthis should be possible in theory. So thinking out loud here how a test might look:One would have to use
$this->container->get('database')->addConnectionInfo()in the test to specify both a 'default' migrate database target and a 'something' target. Then one would need to instantiate a source plugin (maybe an existing one, or preferably a dedicated testing one) once with a 'target' configuration and once without. I haven't tried it but if Migrate utilizes the regular plugin factory mechanism that shouldn't be too hard. And then one would have to call$source_plugin->getDatabase()on the two different plugins and verify that the right one is returned.Having thought about that that actually seems fairly doable, will take a stab at it. Hopefully later today, but maybe next week, so feel free to beat me to it!
Comment #8
tstoecklerI started writing a test for this, but that's not as easy as I thought, because you cannot actually use the
fakedatabase backend withDatabase::getConnection(). Thus, we would actually need a database connection for running the test, which would rule out PhpUnit. Now we could write aKernelTestBaseand somehow muck with the test database connections and re-use those or add an additional migrate prefix or whatever, but that feels fairly terrible in terms of hackiness, TBH. Not sure that's worth it for such a trivial test.Comment #9
benjy commentedWrote a web test.
Comment #10
tstoecklerAwesome, @benjy! I never would have thought of that. Very nice.
Setting this back to RTBC. I hope this doesn't count as me RTBCing a patch I worked on myself, because it was already RTBC before, and the remaining concerns have now been adressed.
Comment #11
benjy commentedSetting to RTBC as per #10 since I think @tstoeckler forgot :)
Patch attached just has some super minor doc changes and combines the getDatabase() call onto one line.
Comment #12
tstoecklerOh god, yes that was rather stupid. Thanks again (!!) @benjy :-)
Comment #13
alexpottComment #14
benjy commentedStraight re-roll.
Comment #15
ultimikeThat's a pretty elegant test. Looks good to me.
-mike
Comment #18
benjy commentedComment #19
alexpottThese seem to have been left behind.
Comment #20
ultimikeUpdated patch and interdiff attached.
-mike
Comment #21
benjy commentedThis looks good, it seems that migrate_source is not longer used anywhere but it should probably still stay since there will be non sql sources in the future.
Comment #22
tstoecklerYes, I think that makes sense. RTBC++
Comment #23
alexpottCommitted afe174d and pushed to 8.0.x. Thanks!