-
Notifications
You must be signed in to change notification settings - Fork 5.6k
[DataFactory]Add AzureMySqlSink and two datasets #6820
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
Conversation
In Testing, Please Ignore[Logs] (Generated from 640aecc, Iteration 6)
|
|
the related SDK built and local tests which run well when testing locally: wenbof-zx/azure-sdk-for-net@a2f1622 |
Automation for azure-sdk-for-pythonA PR has been created for you based on this PR content. Once this PR will be merged, content will be added to your service PR: |
Automation for azure-sdk-for-goThe initial PR has been merged into your service PR: |
|
Can one of the admins verify this patch? |
...atafactory/resource-manager/Microsoft.DataFactory/stable/2018-06-01/entityTypes/Dataset.json
Show resolved
Hide resolved
| } | ||
| }, | ||
| "AmazonRedshiftTableDataset": { | ||
| "x-ms-discriminator-value": "AmazonRedshiftTable", |
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.
AmazonRedshiftTable [](start = 35, length = 19)
So you're adding a new discriminator value to an existing stable API. The SDK generated from the swagger before the change will be able to deal with the discriminator value of "AmazonRedshiftTable" because it's modeled as a string, but it will not be able to deserialize the payload specific to AmazonRedshiftTable. This unfortunately makes it an SDK breaking change. Can you add this in a new API version? #Closed
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.
Sure. it will be generated in a new API version when making changes to SDK. #Closed
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.
as similar as this SDK change where you can see that we change the API version Azure/azure-sdk-for-net#7044 #Closed
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.
To generate a new API version when making changes to SDK, you need the swagger to exist for the new API version, no?
In reply to: 310406114 [](ancestors = 310406114)
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.
right. the order I understand is also the same as you : merge swagger change first, then generate SDK based on the latest swagger. #Closed
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.
the new SDK version is always built based on the latest swagger. which means the old SDK were built based on swagger at specific time and then kept intact there. #Closed
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.
Let's not assume. Can you verify the behavior? What I want to know if it will throw. If the SDK just accepts the payload even if the user can't really interact with it, I'd be ok with that.
@michaeljqzq, can you chime in here as well? What is the behavior with the generated SDK if a new discriminator value is being returned in the backend, but the SDK doesn't know about it yet? Will it throw an exception? #Closed
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 double checked our changes on SDK and can confirm that we manually changed the version and appending the new changes on existing one every time to the new version. @hvermis could you please also help confirm as well? thanks. #Closed
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.
We do not update the API version. This is a known behavior and we have been adding new types like this. Our customers are aware of this. #Closed
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.
@wenbof and @hvermis, you are not actually answering my question, which is delaying this review. I'm not asking whether you have done this before (you clearly have). Azure is a distributed system. There's no mechanism to ensure that all customers simultaneously upgrade to latest and greatest SDK that you have generated, which is why we have breaking changes guidance.
So I will ask the question again in a different way. Let's say you have SDK v2 that supports connectors a and b and SDK v3 that supports connectors a, b, and c. User A has been happily using SDK v2 to manage resources using connectors a and b. Suddenly user B creates resources using connector c in the same subscription or RG via SDK v3.
What will User A now see when he/she queries for all resources?
- Will the old SDK v2 throw an exception?
- Will the responses deserialize successfully but incompletely?
Please pick either answer 1 or 2. #Closed
...tafactory/resource-manager/Microsoft.DataFactory/stable/2018-06-01/entityTypes/Pipeline.json
Show resolved
Hide resolved
majastrz
left a comment
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 added some questions. Please take a look.
|
|
@majastrz could you please check whether you have any further concerns or comments? thanks. |
majastrz
left a comment
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.
Signed off from ARM side.
Latest improvements:
MSFT employees can try out our new experience at OpenAPI Hub - one location for using our validation tools and finding your workflow.
Contribution checklist:
ARM API Review Checklist
Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.
Please follow the link to find more details on API review process.