Problem/Motivation
The API documentation of MigrateSourceInterface::getIds() needs minor improvements.
Many improvements discussed under this issue were already done as part of #2783715: Entity destination ID schema should match entity ID definition. Therefore the scope of this issue was reduced to minor improvements of the phrasing.
Proposed resolution
Improve the phrasing.
Remaining tasks
Review
Commit
User interface changes
None.
API changes
None.
Data model changes
None.
Original report by generalredneck
currently the documentation reads
Return value
array Array keyed by source field name, with values being a schema array describing the field (such as ['type' => 'string]).
It would be helpful if this was more thoroughly documented. Example, there is the ['alias'] key used in Drupal\node\Plugin\migrate\source\d7\Node. Also there is lack in the documentation of the allowed types... Integer and String are the only ones I know of so far.
Comment | File | Size | Author |
---|---|---|---|
#26 | interdiff-2728869-23-26.txt | 931 bytes | masipila |
#26 | 2728869-26.patch | 2.12 KB | masipila |
#23 | interdiff-2728869-17-22.txt | 1.89 KB | masipila |
#23 | 2728869-22.patch | 2.11 KB | masipila |
#19 | interdiff-12-17.txt | 766 bytes | pk188 |
Comments
Comment #2
mikeryanThe schema arrays here are the same ones used in hook_schema() (see https://www.drupal.org/node/159605) - perhaps an @see would be helpful.
The 'alias' is a migrate extension, that should be documented here.
Comment #3
eojthebraveRegarding the 'alias' key. It looks like this is currently only used in \Drupal\migrate\Plugin\migrate\source\SqlBase::initializeIterator, where it's used to determine which field from the source query is the one in question.
Example:
$field_name = $field_schema['alias'] . '.' . $this->query->escapeField($field_name);
So maybe adding something like; "In addition, the migrate system uses an 'alias' key to distinguish between ambiguous field names in some situations. For example when a SQL source query joins two tables with the same field. Providing an optional alias results in using {alias}.{field_name} being used as the ID field."
Or something like that. While I understand what is going on here I had a hard time figuring out how to explain this in a generic way.
I find it a little bit weird that this is documented on the interface, but not necessarily implemented every time. For example, how does the 'alias' key apply if you're using a JSON source? How would you even know what to set it to in that case?
Comment #5
quietone CreditAttribution: quietone as a volunteer commentedMake this a child of the migration documentation Meta issue.
Comment #7
quietone CreditAttribution: quietone as a volunteer commentedThe documentation for getIds was greatly improved by @claudiu.cristea in #2783715: Entity destination ID schema should match entity ID definition. I've added the suggested text in #3. Also moved the first example to it's own paragraph and added an 'Examples:' heading. At least for me, it is easier to both skim the examples and to find the related text.
Comment #8
phenaproximaSelf-assigning for review.
Comment #9
phenaproximaLet's say "column names", since "field" is a loaded term in Drupal. Also, can we have a hyphen after "field names", not a comma?
"Same field" is weird phrasing. How about "...joins two tables which have some of the same column names"? Let us also strike the word "optional" from this line; alternately, we can remove the final sentence altogether because it is an implementation detail specific to SqlBase and therefore arguably does not belong on the interface.
Comment #10
gaurav.kapoor CreditAttribution: gaurav.kapoor at OpenSense Labs commentedComment #11
phenaproximaThanks! Small thing:
There needs be a space after "names", before the hyphen, and "source" exceeds the 80-character limit for the line.
Other than that, setting back to NW until #9.2 is addressed.
Comment #12
gaurav.kapoor CreditAttribution: gaurav.kapoor at OpenSense Labs commented@phenaproxima Fixed 10.1 and regarding 9.2 as per your suggestion i removed last sentence of the paragraph.Keeping it to Needs work for now.
Comment #13
heddnUnless I'm missing something here, I think all feedback has been addressed. I did a review of the docs changes and the description of getIds() seems to make sense to me. The two odd things that previously were a bit mysterious are now explained: alias and field storage settings.
Comment #14
Gábor Hojtsyby *the* SqlBase source plugin?
Comment #15
mikeryanActually, should the SqlBase-specific 'alias' really be documented in MigrateSourceInterface?
Comment #16
heddnre: #15, I think the idea was to provide an example of how custom values could be stored in the ids. Should this be spelled out more clearly?
Comment #17
pk188 CreditAttribution: pk188 at OpenSense Labs commentedComment #18
heddnPlease provide an interdiff. I cannot tell what the changes are without one. See https://www.drupal.org/documentation/git/interdiff
Comment #19
pk188 CreditAttribution: pk188 at OpenSense Labs commentedComment #20
heddnI think we can do better English here. The phrasing doesn't flow.
And per Mike's comment, let's add an @see to the SqlBase plugin, and shorten the description here a little more to give the idea that there is use of passing along additional key/values. But to *really* read up on it, go see the examples in their real location.
Comment #22
masipila CreditAttribution: masipila as a volunteer commentedI'll wrap this quite old api documentation issue later today.
Comment #23
masipila CreditAttribution: masipila as a volunteer commentedOne more old API documentation issue to be finalized, here we go.
Re: #20
1. This patch addresses the 'flow' of the phrasing. I also improved the flow of the description of the first code example.
2. There was already @see \Drupal\migrate\Plugin\migrate\source\SqlBase
3. @heddn, did you mean by your last comment in #20 that we should remove the last code example? I did not remove it, I think it is a good example. If the developers are reading the API documentation of the SqlBase source plugin class they can then follow a link to MigrateSourceInterface::getIds() from that context.
4. I also separated the code examples from each other by one newline. The coding standards say that we must not use a blank line between the text that explains the code sample and the code sample itself. The newlines I added are to separate examples from each other i.e. we are not talking about newlines between the code and its description.
Cheers,
Markus
Comment #24
phenaproximaTwo supernits! I've outdone myself.
There should be a comma after 'alias'.
There should also be a comma after 'example'.
Comment #25
heddnre #23 you've addressed my feedback quite well. There's one more nit I see not called out by Adam. Its pasted below. I think we need the word to connect the phrases more cleanly.
The most common setting passed along to the ID definition...
Comment #26
masipila CreditAttribution: masipila as a volunteer commentedThree nits from #24-25 addressed with two line changes, haha, beat you by one! :D
Issue summary updated to help committers.
Cheers,
Markus
Comment #27
heddnAll feedback addressed.
Comment #30
Gábor HojtsyThanks all, this is clearly an improvement even if just a small one :)
Comment #31
generalredneckI do appreciate the inclusion of the issue creators in the credit... this doesn't happen nearly as often as it should.