-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(AIP-123): enforce singular as ID segment #1403
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm struggling to comprehend this one in much detail (not enough coffee?) so I only have very superficial comments. I may have another look later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I haven't re-reviewed everything - I'm just approving on the grounds that my comments have all been addressed. Getting another review from someone else would probably be a good idea.)
|
||
if !utils.IsSingletonResource(m) { | ||
singular = fmt.Sprintf("{%s}", strcase.SnakeCase(singular)) | ||
nn = fmt.Sprintf("{%s}", nn) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you have a non-nested singleton will this be empty as nn
will be unset? Or is that case impossible?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think non-nested singletons are possible since they depend on the lifecycle of another resource e.g. when X is created, XSingleton is also created. I don't know of any examples of them either.
That said, this specific line wouldn't be executed b.c the check "if no singleton" above would skip this in that case.
but having top-level singletons shouldn't be a thing...this did remind me though that I needed to better handle that case in the "is root level" check (fixed).
Lint for the `plural` appearing as the collection segment in resource patterns. Special handling for nested resource collections that potentially stutter with the pattern, affording a reduced collection segment in the pattern. See #1403 for more details. The nested plural form is derived in a round about way where we check to see if the parent resource singular (via the resource ID segment) is a prefix of the child collection segment. We use the parent singular because the child plural wouldn't use the parent plural as the prefix in a "compound"/nested name, it would use the parent singular. This prefix is trimmed if it matches, leaving a reduced child collection name that is already pluralized. For internal bug http://b/343466943
Fair warning, this is a big PR.
Enforces the following guidance from AIP-123:
It takes special consideration for stuttering child resource names as documented in AIP-122 Nested Collections. It does this in a somewhat awkward way in that it compares the resource
singular
form insnake_case
to the parent resource ID segment (if present). If the parent ID segment is a prefix of the snake_casesingular
for the resource, then it is considered nested e.g.{author}
parent ID segment compared toauthor_credit
would be considered nested and eligible for reduction to justcredit
in the resource pattern(s). This handles child resources that are singletons as well.It only recommends this reduction in the following cases:
The same needs to be done for
plural
as collection ID in resource patterns and they should be merged/released together.For internal bug b/343465929
P.S.: also updates the "bugged"
resource-singular
rule documentation - copy+paste strikes again.