Closed (fixed)
Project:
Drupal core
Version:
8.4.x-dev
Component:
migration system
Priority:
Minor
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
21 Mar 2017 at 21:31 UTC
Updated:
26 Oct 2017 at 08:00 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
jofitzAdded configuration keys. Not quite sure what else to include on this one because it is an abstract and so examples aren't really applicable.
Comment #3
heddnThis isn't strictly true. Contrib doesn't have to use this base class. Let's remove the word "all" and I'm fine. Yes, I know, it is a super small nit.
Comment #4
jofitzGood point, @heddn. Change made.
Comment #5
heddnDocs seem sufficient, given this is an abstract class.
Comment #6
wim leersViolates 80 cols rule.
Comment #7
heddnA trivial fix of the comment length. Docs only change. Putting this back to RTBC.
Comment #8
gábor hojtsyAs per issue summary "make sure [...] working with translations are included. Add suitable examples too.". So looks like this is not getting to where it intended to go.
Comment #9
heddnI must be missing something then, because I cannot find anything special for i18n migrations. Which means we probably need an IS update. I do see in getIds() where in I18nProfileField we are adding multiple columns to make the ids unique, but that has another issue to update its docs in #2728869: Document public function MigrateSourceInterface::getIds return value better. There doesn't seem to be anything else needed in the source base plugin for i18n migrations.
Comment #10
quietone commentedYes, there isn't anything about translations in SourcePluginBase, so nothing to do there. All available configuration keys are listed, so that is done.
The keys are all optional, so need to have 'optional' added. And, I think the descriptions need to be more specific.
These should indicate the data type of these keys and say something like, "If set xyz will happen". And can we make the language consistent, two being with 'Whether' and one with 'Flags'.
We should tell the reader that this is an array of the name of the property begin used for high water and it's table alias.
Comment #11
pritishkumar commentedComment #12
heddnthis doesn't really do what was asked in #10. Specifically, it isn't more specific. Nor is does it touch the high_water_property.
Comment #13
pk188 commentedComment #14
heddnThis doesn't seem like a troublesome Novice issue. But before posting a patch, please review all the comments in #8 and #10. There's been a couple patches now that have very little value and haven't done really anything. Except give the possibility of commit credit. Please be careful to review the feedback and list what you are providing in the patch and what is still outstanding.
There's no examples as requested in #8.
There should be a space between )(
This isn't any more specific yet either.
Missing (optional). Missing better description too.
Comment #15
mikeryanhigh_water_property is not an "array of names" - it is an array containing a single property name, an an optional table alias.
Comment #16
pk188 commentedFixed #14 and #15. Working on example as mentioned in #8 and update it once completed.
Comment #17
pk188 commentedComment #19
pk188 commentedComment #20
shashikant_chauhan commentedFixed 80 character length issue.
Comment #21
pk188 commented@shashikant_chauhan in your patch there are more than 80 characters in a line.
Comment #22
shashikant_chauhan commented@pk188, You don't have to count the characters in patch file instead you should count in file after applying the patch.
See https://www.drupal.org/docs/develop/standards/coding-standards#linelength for more information.
Comment #23
maxocub commentedAssigning for review
Comment #24
maxocub commentedThis documentation doesn't seem very helpful to me and the formulation could be improved.
Those configuration keys are associated with the class properties, which are already documented, and should be coherent. For instance, cache_counts, skip_count & track_changes are said to be boolean on the properties, but integers here.
Also, even if this is an abstract class, we should and can provide some examples, something like:
It should also be mentioned that the high_water_property cannot be used with the track_changes property, as said on line 179:
throw new MigrateException('You should either use a highwater mark or track changes not both. They are both designed to solve the same problem');So this should absolutely be included in the documentation and we should have code examples for both possibilities, explaining their differences.
Comment #26
edysmpComment #27
edysmpComment #29
tacituseu commentedUnrelated failure.
Comment #30
quietone commentedBoolean isn't necessary, and we haven't added the type like this in other migrate documentation.
high_water_property is optional
This needs to be move to just below 'available configuration keys' and not in an example. It is vital information. And maybe change it to 'The high_water_property and track_changes are mutually exclusive.'
The examples need to explain what they do. That is, what happens when the source plugin is configured as in the example.What will happen? What will not?
Comment #31
maxocub commentedI don't think this should be tagged Novice since it requires an good understanding of the migration system.
Back to Needs work.
Comment #32
jofitzRemoved instances of "(boolean)".
Marked high_water_property as optional.
Moved and edited the high_water_property sentence.
Added explanation to the examples.
Comment #33
heddnNit: comma between set, and the rest of the sentence.
Nit: Add comma. And if set, /do/ not attempt to count.
comma or period should be inserted before word, "which".
Comma after, "In this example". And another comma after word "true".
Comment #34
dhruveshdtripathi commentedChanges made according to comment #33
Comment #35
quietone commentedOne more thing, sorry. I find this sentence a bit clumsy at the end.
This example uses the plugin "some_source_plugin_name" and caches the count of available source records to save calculating every time count() is called.
Maybe just change "every" to "it every"?
Comment #36
jofitzMade change suggested by @quietone in #35.
Comment #37
heddnAll feedback is now addressed.
Comment #38
heddnI'm doing an implementation with high_water_property right now. And 1) it is complicated, 2) this little two line comment isn't helping.
From getHighWatermark()
From getHighWaterField()
It looks like an array keyed by 'name' and (optionally) 'alias'.
The values of name and alias are concatenated with a period and used in SqlBase for a db query condition.
So, let's reword this:
high_water_property: (optional) It is an array of key/values for a column name and (optional) alias in the source database that defines a timestamp stating the time the import was last run. If the mark is set, only content with a higher timestamp will be imported.
And it looks like our example should add the alias part to the docs.
Should be:
The above will get converted into n.changed when running the database query.
Comment #39
heddnTagging.
Comment #40
rakesh.gectcrComment #41
heddnAddressing my own feedback.
Comment #42
maxocub commentedBeautiful.
Comment #43
jofitzVery minor punctuation correction.
Comment #44
jofitzI think this can be safely returned to RTBC!
Comment #47
gábor hojtsyThanks all for making sure this looks good! Committed to 8.5.x and cherry-picked to 8.4.x.