Skip to content

2.18.0

Latest
Latest

Choose a tag to compare

View all tags
@Laurianti Laurianti released this 21 Oct 12:40
· 2 commits to main since this release
v2.18.0
487ba89
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

ChromaDotNet.Client and ChromaDotNet.Client.DependencyInjection 2.18.0, released together.

New

  • ChromaReadRetries.MinDelay: a read never goes again at once. The delay before a new attempt is a random time from MinDelay to the smaller of MaxDelay and BaseDelay times 2 to the attempts that went again before. new ChromaReadRetries(maxAttempts, minDelay, baseDelay, maxDelay) takes it, from zero to the base; the constructor without it takes 0.8 times the base, the lower bound of the jitter of Azure.Core. The default now waits 40 to 50 ms, then 40 to 100 ms and 40 to 200 ms; ChromaReadRetries.None does not change.
  • Collections created when missing: client.GetCollectionClient(name, createIfMissing: true) gets or creates the collection at its first operation, with one request that the operations starting before it ends share, and await client.GetOrCreateCollectionClientAsync(name) does it at once. Both take a ChromaCollectionDefinition too, keep the collection, and create it again, empty, when it is deleted elsewhere.
  • AddChromaClientFromServices and AddKeyedChromaClientFromServices make the options from the services when the client is resolved, so the address can come from IConfiguration or IOptions of the application.

Fixes

  • A value that is not a text under the metadata key chroma:document, where Chroma keeps the document of a record, throws an ArgumentException before the request, in AddAsync, UpdateAsync and UpsertAsync. Such a value, like a number, a Boolean, a list, or a null in an update or an upsert, makes Chroma 1.0.0 to 1.5.9 fail every add and get of the server, on every collection, until it restarts (KD-58). The same holds for the null of a deleted document or the mark that WithDocumentCopyKey or WithDocumentDeletionKey would write under that key.
  • A text under chroma:document goes as before and sets the document, also a Guid, a date or a byte[], which the client writes as text. The other keys with the prefix chroma: go as before too.
  • The release notes of the packages link the GitHub release of their version. The ones of 2.15.0 to 2.17.0 were still those of 2.14.0.

Docs

  • docs/COMPATIBILITY.md: KD-58. docs/metadata.md: the key chroma:document. docs/errors.md: MinDelay. docs/collections.md: collections created when missing. docs/dependency-injection.md: options made from the services.
  • The migration guide from 1.x says what a real migration had to do: the URI, the collection client, the handlers to remove, dependency injection and the behaviors that differ from 1.x.

Nothing breaks for the existing code: every setting of ChromaReadRetries that was valid stays valid.

NuGet: https://www.nuget.org/packages/ChromaDotNet.Client/2.18.0 and https://www.nuget.org/packages/ChromaDotNet.Client.DependencyInjection/2.18.0

Assets 7
Loading