Fix Schema type to reference itself in its child properties #222
Conversation
| @@ -75,7 +75,7 @@ export class ChatSession { | |||
| * | |||
| * Fields set in the optional {@link SingleRequestOptions} parameter will | |||
| * take precedence over the {@link RequestOptions} values provided at the | |||
| * time of the {@link GoogleAIFileManager} initialization. | |||
| * time of the `GoogleAIFileManager` initialization. | |||
There was a problem hiding this comment.
Why didn't the @link work here?
There was a problem hiding this comment.
api-extractor/documenter doesn't really handle multiple entry points and there's 2 separate entry points from the main package and from the /server subpath. ChatSession is under the main entry point and GoogleAIFileManager is in the subpath. We run api-documenter separately on each and the two processes don't know about each other. That's why we have a fork of api-documenter in the firebase-js-sdk repo, we wrote custom code to handle multiple entry points. I don't want to use the fork if possible because it's not getting any of the bug fixes and improvements being made to the main branch of api-documenter.
However, now that I've written all that, I realize this is in ChatSession, and this was probably originally a copy-paste mistake, as GoogleAIFileManager doesn't have anything to do with ChatSession. It looks like all the bad GoogleAIFileManager links were typos in the non-server-only entry point, which shouldn't have any references to GoogleAIFileManager at all. I've fixed them to refer to the correct initialization location (GoogleGenerativeAI.getGenerativeModel()).
| /** Optional. The items of the property. {@link FunctionDeclarationSchema} */ | ||
| items?: FunctionDeclarationSchema; | ||
| /** Optional. The items of the property. */ | ||
| items?: Schema; |
There was a problem hiding this comment.
This seems a little odd to me. So a Schema can have Schemas?
There was a problem hiding this comment.
Yes. It's always been that way in the proto: https://source.corp.google.com/piper///depot/google3/google/ai/generativelanguage/v1main/content.proto;l=489
We moved away from using the generic Schema type in the SDK for function calling because top-level Schemas had different requirements from Schemas nested in properties or items so we wanted to distinguish and provide more specific guidance for users. It's less clear what the difference is for the top-level responseSchema is so we should leave it as the generic Schema until we have any confirmation that it should be different.
As long as there is a generic Schema, its children should also be generic Schema and not extended versions of itself that other extended versions may not know about.
|
The renaming is not reflected in any documentation! See: https://ai.google.dev/gemini-api/docs/json-mode?lang=node |
Note: There are a lot of docs changes, feel free to collapse the docs folder in the PR page while reviewing code and then look at them separately later.
Schemawas incorrectly referencingFunctionDeclarationSchemafor the value of itsitemsarray andpropertiesmap. This happened when we genericizedSchemaand forgot to do the same for all its properties.As part of this change I also renamed
FunctionDeclarationSchemaTypetoSchemaType, as it is also used for JSON response schema, and may be used for even more use cases going forward.I've also made some changes to fix some docs errors regarding
GoogleAIFileManagerandSingleRequestOptionsthat were causing them to be left blank in some docs when called with a{@link}.