Skip to content
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

OpenAPI emitter deduplicating parameters #1118

Closed
timotheeguerin opened this issue Oct 3, 2022 · 4 comments · Fixed by #1577
Closed

OpenAPI emitter deduplicating parameters #1118

timotheeguerin opened this issue Oct 3, 2022 · 4 comments · Fixed by #1577
Assignees
Labels
design:needed A design request has been raised that needs a proposal

Comments

@timotheeguerin
Copy link
Member

timotheeguerin commented Oct 3, 2022

As part of this PR(#1115) fixing various issue around parent and sourceProperty reference in projections the result was that parameters where always inlined when using KeysOf.

import "@cadl-lang/rest";

using Cadl.Http;
using Cadl.Rest.Resource;

op test(...KeysOf<Pet>): void;

model Pet {
  @key("petId")
  id: string;
}

One option is to call @friendlyName in KeysOf but just doing that result in the shared parameter to be called PetKeys if there is a single key.

@ghost ghost added the Needs Triage label Oct 3, 2022
@timotheeguerin timotheeguerin added design:needed A design request has been raised that needs a proposal and removed Needs Triage labels Oct 4, 2022
@timotheeguerin timotheeguerin added this to the [2022] December milestone Oct 4, 2022
@johanste
Copy link
Contributor

johanste commented Oct 4, 2022

We do want to trace the lineage of the KeysOf to the original model type that it came from. For Python, an example of code we (want to be able to emit) is:

class Cat:
    id: str
    name: str

class CatClient:
    def update_cat(self, cat: str | Cat, *, name: str | None = None) -> Cat: ...

In other words, take either the key properties of a resource or an instance of the resource as the argument to the method.

@nguerrera
Copy link
Contributor

nguerrera commented Jan 25, 2023

I've put together a proposal in the form of a PR that implements it:

#1577

We can review the PR description and small diff in the design meeting.

@nguerrera
Copy link
Contributor

This was approved.

@nguerrera nguerrera removed the design:needed A design request has been raised that needs a proposal label Jan 26, 2023
@markcowl
Copy link
Contributor

closing in favor of the PR

@nguerrera nguerrera added the design:needed A design request has been raised that needs a proposal label Jan 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design:needed A design request has been raised that needs a proposal
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants