cadl-ranch-specs, add basic test case of clientInitialization #727
Conversation
🦋 Changeset detectedLatest commit: 7fb502f The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
There was a problem hiding this comment.
We may need add more complex cases:
- more complex client hierarchy, e.g. more than 3 layer clients
- co-operate with @client / @operationGroup decorator
- with paramMaps to map a parameter to the property of the Client initialization Model
- a senario that not all operations has the bumped parameter
Wondering whether we need to have a subfolder for different scenarios. And this be in a "basic" folder. As the characteristic of the "client hierarchy", some of them cannot co-exist in same main.tsp. E.g. client by namespace/interface cannot be in same file as client by |
Yes. Those are separate scenarios and may not co-exist and should be placed in different folder. |
This is only part of the support for Azure/autorest.java#2428 cadl-ranch Azure/cadl-ranch#727 user code ```java InitializationClient client = new InitializationClientBuilder() .name("client1") .buildClient(); client.action(); ```
weidongxu-microsoft
requested review from
iscai-msft,
lmazuel,
m-nash,
joheredi,
srnagar,
tadelesh and
timotheeguerin
as code owners
weidongxu-microsoft
changed the title
This is only part of the support for Azure/autorest.java#2428 cadl-ranch Azure/cadl-ranch#727 user code ```java InitializationClient client = new InitializationClientBuilder() .name("client1") .buildClient(); client.action(); ```
weidongxu-microsoft
changed the title
|
@weidongxu-microsoft please hold this. i'm going to redesign all the client related thing in tcgc to consolidate all things related to clients, it may cause changes for decorator. |
Sure. Note that Face API already uses this decorator in their specs (and Java emitter also uses the I guess .NET also uses the TCGC info. I am fine if you want to break some, though. |
| @route("/sub-client/{name}:action") | ||
| action(@path name: string): void; |
There was a problem hiding this comment.
I'm not sure, maybe add another parameter that will be taken in method signature, as a contrast?
There was a problem hiding this comment.
Sure, I will first update to our local test first, as this one likely going to take time.
microsoft/typespec#5027
Link Azure/autorest.java#2972 Current limitation - sub client need to be in same namespace of its parent. Feature behind `enable-subclient` option (`false` means client/operationGroup; `true` means all client, with client having accessor to get subclient) unbranded openai https://github.com/joseharriaga/openai-in-typespec ## Bug to be fixed in other PRs (relate to unbranded openai, but unrelated to this feature -- moved to #5047) - #5026 - #5030 - #5028 - #5031 ## Test 1. cadl-ranch PR Azure/cadl-ranch#727 (also tried on test with more than 2 level subclient -- nested namespaces) 2. openai unbranded https://github.com/joseharriaga/openai-in-typespec/compare/main...weidongxu-microsoft:java-sub-client?expand=1 ([apiview](https://apiview.dev/Assemblies/Review/b974bacf316c495aa5c30ce0b7e07b1c/d1d7278c251d4805b189fd238714897d#com.openai.OpenAIClient)) 3. Face API Azure/azure-sdk-for-java#42875
Cadl Ranch Contribution Checklist:
@scenarionames. Someone can look at the list of scenarios and understand what I'm covering.@scenarioDocs for extra scenario description and to tell people how to pass my mock api check.