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

Binder models tcgc #2759

Open
wants to merge 108 commits into
base: main
Choose a base branch
from
Open

Binder models tcgc #2759

wants to merge 108 commits into from

Conversation

joheredi
Copy link
Member

@joheredi joheredi commented Aug 19, 2024

Summary of Changes in this PR

  1. use binder to manage model references
  2. deserializer support. fixes Fill in gaps for Deserialization #2625
  3. refactor of the operation helper in both serialization and deserialization. partially fix Serialization Followup work #2619 combine the previous serializeUtils/deserializer logic with serializer/deserializer.
  4. sdkPackage.models related adoption. Implement TCGC's SdkPackage types #2406
  5. client initialization adoption fixes Support client-level parameter defined @clientInitialization #2795
  6. use tcgc generated name for anonymous model
  7. rename RLC context name with tcgc client name.
  8. stop normalize the property name Should we cast property name automatically in modular? #2645
  9. refactor of all unit test to take options parameter instead of introducing long signature list.
  10. modular models for multiclient support. fixes revisit modular models generation in multi clients #2611
    a. generate one copy of models outside of the subclient folder of multi-client case.
    b. move operation options inside the api folder.

TCGC related issues

  1. [Bug]: should we have apiVersion lifted to client initialization if not all operation has this parameter? typespec-azure#1595
  2. [Bug]: EnumMember type as a clientDefaultValue? typespec-azure#1598
  3. [Bug]: Discriminated subtype is missing in models from sdkPackages  typespec-azure#1605
  4. [Bug]: fail to extract clientDefaultValue for apiVersion in server  typespec-azure#1608

@qiaozha qiaozha self-assigned this Aug 28, 2024
}

// @public (undocumented)
export interface DeleteDataRequest {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this seems to be a new model. not sure where it comes from

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so is this expected?

@qiaozha qiaozha requested a review from dgetu September 30, 2024 07:34
@@ -439,6 +455,10 @@ export interface NetworkAnalyticsClientOptionalParams extends ClientOptions {
apiVersion?: string;
}

// @public (undocumented)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

docs missing.

Comment on lines +56 to +60
timestamp_granularities: !item["timestampGranularities"]
? item["timestampGranularities"]
: item["timestampGranularities"].map((p: any) => {
return p;
}),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feels like this is a no-op? Could we just generate timestamp_granularities: item["timestampGranularities"] or am I missing something?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, but I was actually struggling between the option of increasing the codegen implementation/runtime complexity by detecting if we need to generate the serializer/deserializer for each type recursively with the risk of some type we may be missing, and the option of just generate the serializer/deserializer any way.

Comment on lines +1002 to +1004
functions: !item["functions"]
? item["functions"]
: functionDefinitionArraySerializer(item["functions"]),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it work to simplify this pattern to something like:

{
  // ...

  functions: item["functions"] && functionDefinitionArraySerializer(item["functions"]),
}

or is there a case where that wouldn't do the right thing?

@@ -990,9 +1034,6 @@ export interface PineconeFieldMappingOptions {
urlField?: string;
}

// @public
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it expected that this is being removed?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be expected.
currently, we will filter the generated types based on their usage here https://github.com/joheredi/autorest.typescript/blob/0d4a12d15dbcfdff103e85804b0fc5fe23c512d8/packages/typespec-ts/src/modular/emitModels.ts#L100-L107 , And in tcgc, this version enum has a special UsageFlag https://github.com/Azure/typespec-azure/blob/main/packages/typespec-client-generator-core/src/interfaces.ts#L703. that's why it gets filtered out.

We have an issue for version union #2680, which we have agreed to generate the api version type as string, but we will generate a KnownXXX enum for it as document purpose.

Because issue #2680 is not completed yet, and if I remember correctly, in our existing releases, @kazrael2119 has manually removed all the version unions when preparing the prs. so, it should not be a breaking.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dgetu I think you have the same comment about this. Let me know if you have different thoughts here.

packages/typespec-ts/src/modular/helpers/clientHelpers.ts Outdated Show resolved Hide resolved
packages/typespec-ts/src/modular/helpers/clientHelpers.ts Outdated Show resolved Hide resolved
createOrReplace(name: string, resource: User, options?: CreateOrReplaceOptionalParams): PollerLike<OperationState<User>, User>;
delete(name: string, options?: DeleteOptionalParams): PollerLike<OperationState<void>, void>;
export(name: string, format: string, options?: ExportOptionalParams): PollerLike<OperationState<ExportedUser>, ExportedUser>;
createOrReplace(name: string, resource: User, options?: CreateOrReplaceOptionalParams): PollerLike<OperationState_2<User>, User>;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

blocking: Naming is broken here

@@ -94,6 +110,10 @@ export declare interface PageSettings {

export declare type ProvisioningState = ResourceProvisioningState | "Provisioning" | "Updating" | "Deleting" | "Accepted";

export declare type ProvisioningState_1 = ResourceProvisioningState | "Provisioning" | "Updating" | "Deleting" | "Accepted";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

check: Type is being generated multiple times. Is this a namespace problem, or an emitter bug?

@@ -313,6 +318,10 @@ export interface ErrorAdditionalInfo {
readonly type?: string;
}

// @public
export interface ErrorAdditionalInfoInfo {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

new orphan model?

Versions,
} from "./models/index.js";
export {
NetworkAnalyticsContext,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why we export NetworkAnalyticsContext to public in classical layer? I think this is implementation detail in this layer.

@@ -34,7 +35,7 @@ export interface BrokerProperties {
// @public
export interface CloudEvent {
data?: any;
dataBase64?: Uint8Array;
data_base64?: Uint8Array;
Copy link
Member

@MaryGao MaryGao Oct 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am a fan of that we should do property normalization especially for azure scope. This could help us generate more idiomatic SDKs. And could ensure consistant property naming style cross SDKs.

TypeSpec authors could have their own style of property naming convention and that style may or may not be suitable for JS/TS language style. So property normalization could help

  • ensure all properties only have one style
  • property naming style is JS/TS style
  • good property name could be better discoverable by user intellisense
  • a typespec property may not be a valid ts property

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants