SDK - Fixed small bug in DSL code that generates unique names for ops #923
Conversation
Before the fix it would generate names as follows: name name-2 name-2-3
Ark-kun
changed the title
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Ark-kun The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
1 similar comment
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Ark-kun The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Ark-kun
deleted the
Fixed-small-bug-in-code-that-generates-unique-names-for-ops
branch
Ark-kun
changed the title
|
Not in favor of creating dependency of the DSL on component. This name sanitization could happen in the second stage of the compiler. |
…flow#923) Before the fix it would generate names as follows: name name-2 name-2-3 After the fix: name name-2 name-3
Unfortunately, that's not the case. It's not about sanitization - it's about uniqueness. Currently, outputs refer to their task by name. If multiple tasks have the same name, the compiler has no idea which op to link to. And given that the PipelineParam can be serialized to string (which might not be a good feature), the problem becomes worse. An example: How would the compiler distinguish between If you can improve this code, I have absolutely no problem with that. |
|
the name was unique, wasn't it? |
Before the fix it would generate names as follows:
name
name-2
name-2-3
After the fix:
name
name-2
name-3
This change is