Add flush proto #327
Add flush proto #327
Conversation
Signed-off-by: vankichi <[email protected]>
📝 WalkthroughWalkthroughThe pull request introduces a new protocol buffer file Changes
Sequence DiagramsequenceDiagram
participant Client
participant FlushService
participant ValdAgent
Client->>FlushService: Flush Request
FlushService->>ValdAgent: Trigger Vector Index Flush
ValdAgent-->>FlushService: Return Index Count
FlushService-->>Client: Return Flush Result with Index Count
This sequence diagram illustrates the high-level interaction of the new flush service, showing how a client can request a flush operation, which triggers the vector agent to flush its index and return the count of indexed vectors. Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (49)
src/google/protobuf/descriptor_pb.d.ts (2)
1229-1230: Consider removing internal bug IDs from open-source comments.
While the status update is helpful, references to internal bug tracking (b/264593489) might not be actionable for external contributors or may cause confusion.
1251-1252: Consider removing internal bug IDs from open-source comments.
Like above, referencing internal bug IDs in open-source code can be less helpful to the broader community and can be confusing.src/vald/v1/vald/flush_pb.grpc-client.js (1)
22-23: Remove redundant "use strict" directive
Modern JavaScript modules are in strict mode by default, so the "use strict" directive is unnecessary.Apply this diff to remove it:
- "use strict";🧰 Tools
🪛 Biome (1.9.4)
[error] 22-23: Redundant use strict directive.
The entire contents of JavaScript modules are automatically in strict mode, with no statement needed to initiate it.
Safe fix: Remove the redundant use strict directive.(lint/suspicious/noRedundantUseStrict)
src/vald/v1/vald/insert_pb.grpc-client.js (3)
51-51: Docs look good and concise.
The change to the overview comment simplifies the description, which can be beneficial for new users; however, ensure the removed details (like any specific error-handling scenarios) are captured in a separate location, if needed.
70-70: Stream method clarity.
This succinct line helps new users quickly understand the method’s purpose. If additional advanced usage details exist, consider linking or referencing them in a separate doc.
79-79: Multi-insert method coverage.
The simplified documentation is consistent with the rest of the file. Ensure any removed troubleshooting details (if previously provided) are still discoverable.src/vald/v1/vald/upsert_pb.grpc-client.js (2)
70-70: Bidirectional streaming doc.
Keeping the doc text direct is an improvement. If you see repeated user confusion, consider an inline reference or link to further details.
79-79: Multi-upsert best practices.
The condensed text is tidy. If you have best practices (e.g., major version conflicts, concurrency tips), referencing them in a separate doc might help advanced users.src/vald/v1/vald/update_pb.grpc-client.js (1)
70-70: Streaming updates.
The simplified docs are consistent with your approach. If needed, consider linking examples of using the streaming method for clarity.src/vald/v1/vald/remove_pb.grpc-client.js (2)
61-61: Remove method doc.
This direct statement effectively conveys the main purpose. If advanced usage or error details were omitted, ensure they’re elsewhere.
88-88: Multi-remove doc coherence.
This streamlined comment efficiently covers the method’s purpose. Ensure the omitted details, if critical, are still documented in a cohesive place.src/vald/v1/vald/remove_pb.grpc-client.d.ts (7)
39-39: Clarify doc wording if needed.
"A method to remove an indexed vector" is sufficiently descriptive. If the removal supports specialized scenarios or returning detailed statuses, consider adding short clarifying statements.
48-48: Consider note on valid timestamp usage.
"A method to remove an indexed vector based on timestamp" is concise, but it could be helpful to mention acceptable timestamp ranges (e.g., UTC-based?).
64-64: Doc clarity for batching.
"A method to remove multiple indexed vectors in a single request" could highlight any constraints or performance considerations.
74-74: Duplicate service description.
Line 74 repeats the same descriptive comment as line 33. Consider whether it's necessary or deduplicate to maintain minimal doc repetition.
82-82: Doc alignment with method signature.
Encourage clarifying that “remove” triggers asynchronous or synchronous actions. Currently, "A method to remove an indexed vector" is fine, but you could specify if immediate effect is guaranteed.
88-88: Provide caution note for timestamp-based removal.
For user clarity, consider noting if passing an invalid or out-of-range timestamp triggers specific exceptions or behaviors.
100-100: Mention performance considerations for MultiRemove.
Multiple vector removal in a single request could have implications on request size or throughput; a short note can help users account for this.src/vald/v1/vald/object_pb.grpc-client.d.ts (5)
41-41: Check if doc should mention any special indexing statuses.
“A method to check whether a specified ID is indexed or not.” might benefit from a note clarifying if partial indexing states or errors occur (e.g., if the ID is scheduled but not fully indexed).
50-50: Optional detail on retrieval process.
“A method to fetch a vector” is purely functional. If partial vectors or specialized metadata exist, referencing them could help.
59-59: Clarify ‘bidirectional streaming’ behavior.
Explicitly note whether the server can push updates or error messages during the streaming for clarity.
83-83: Repeat of the service doc.
"Object service provides ways to fetch indexed vectors." is repeated from line 35. Consider removing or referencing line 35’s doc to reduce duplication.
103-103: Highlight streaming benefits.
“A method to fetch vectors by bidirectional streaming” is succinct. Consider noting typical use cases (e.g., large batch retrieval).src/vald/v1/vald/filter_pb.grpc-client.js (11)
61-61: Document potential advanced usage.
"A method to search object." is fine but might consider clarifying advanced searching (e.g., vector similarities, filtering).
70-70: Clarity on “multiple objects.”
"A method to search multiple objects." might specify if it does so in parallel or sequentially behind the scenes, if relevant.
88-88: Insert doc is clear.
“A method insert object.” is succinct. Minor grammar tune-up: "A method to insert an object."
97-97: Doc for streaming insert.
Similar grammar note: “Represent the streaming RPC to insert object by bidirectional streaming” → “Represents the streaming RPC…”
106-106: Multiple insert doc.
"A method to insert multiple objects." is straightforward. If there's an upper limit on batch sizes, consider clarifying.
115-115: Update doc consistency.
"A method to update object." Keep consistent with "A method to insert an object." (add “an” for consistency).
124-124: Streaming doc improvement.
Again, "A method to update object by bidirectional streaming." could mention potential concurrency nuances or ordering constraints.
133-133: Multi-update doc.
"A method to update multiple objects." Confirm if partial failures are possible, and how the method surfaces them.
142-142: Upsert doc clarity.
"A method to upsert object." is fine. If there's a difference from standard update/insert (like merging), mention it briefly.
151-151: Grammar fix.
"A method to upsert object by bidirectional streaming." → "A method to upsert an object by bidirectional streaming."
160-160: Handling batch upserts.
"A method to upsert multiple objects." might clarify that if some objects already exist, they’ll be updated, while new ones will be created.src/vald/v1/vald/search_pb.grpc-client.js (12)
61-61: Doc for “search.”
"A method to search indexed vectors by a raw vector." conveys it well. If advanced filter options exist, mention them.
70-70: Simplify or unify doc references.
"A method to search indexed vectors by ID." matches line 61 style. If ID-based search is a direct or approximate search, clarify.
79-79: Clarify multiple vectors scenario.
"A method to search indexed vectors by multiple vectors." might note if responses are aggregated or streamed individually.
88-88: Doc repetition.
"A method to search indexed vectors by multiple IDs." If the approach is identical to multi vectors, unify doc as needed.
97-97: Single request batch doc.
"A method to search indexed vectors by multiple vectors in a single request." Possibly highlight any size or performance constraints.
106-106: Single request by multiple IDs.
Likewise, mention relevant constraints, e.g., maximum ID batch.
115-115: Distinguish linear search from approximate methods.
"A method to linear search indexed vectors…" is accurate but may need mention if truly linear or approximate.
124-124: Doc clarity for linear search by ID.
"A method to linear search indexed vectors by ID." is succinct. If the method has performance differences from approximate search, consider clarifying.
133-133: Streaming linear search doc.
"A method to linear search indexed vectors by multiple vectors." might note how concurrency is handled in streaming.
142-142: Stream linear search by ID doc.
"A method to linear search indexed vectors by multiple IDs." is solid—same advanced note about concurrency or possible error reporting.
151-152: Single request batch doc.
"A method to linear search indexed vectors by multiple vectors in a single request." If partial failures occur, note how they’re returned.
161-162: Single request batch by ID doc.
"A method to linear search indexed vectors by multiple IDs in a single request." Add clarifications on batch size if relevant.src/vald/v1/vald/filter_pb.grpc-client.d.ts (2)
72-72: Docstring alignment
"A method insert object." might be slightly missing an article, but remains clear enough.
174-174: Docstring alignment
"A method insert object." might benefit from an article ("A method to insert an object.").src/vald/v1/vald/flush_pb.js (1)
1-56: Remove the redundant "use strict" directive
Modern JavaScript modules are in strict mode by default. Consider removing the "use strict" statement to avoid lint warnings.🧰 Tools
🪛 Biome (1.9.4)
[error] 22-23: Redundant use strict directive.
The entire contents of JavaScript modules are automatically in strict mode, with no statement needed to initiate it.
Safe fix: Remove the redundant use strict directive.(lint/suspicious/noRedundantUseStrict)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (25)
Makefile(1 hunks)src/google/protobuf/descriptor_pb.d.ts(4 hunks)src/google/protobuf/descriptor_pb.js(3 hunks)src/vald/v1/vald/filter_pb.grpc-client.d.ts(9 hunks)src/vald/v1/vald/filter_pb.grpc-client.js(13 hunks)src/vald/v1/vald/flush_pb.d.ts(1 hunks)src/vald/v1/vald/flush_pb.grpc-client.d.ts(1 hunks)src/vald/v1/vald/flush_pb.grpc-client.js(1 hunks)src/vald/v1/vald/flush_pb.js(1 hunks)src/vald/v1/vald/index.d.ts(2 hunks)src/vald/v1/vald/index.js(1 hunks)src/vald/v1/vald/index_pb.grpc-client.d.ts(0 hunks)src/vald/v1/vald/index_pb.grpc-client.js(0 hunks)src/vald/v1/vald/insert_pb.grpc-client.d.ts(3 hunks)src/vald/v1/vald/insert_pb.grpc-client.js(4 hunks)src/vald/v1/vald/object_pb.grpc-client.d.ts(4 hunks)src/vald/v1/vald/object_pb.grpc-client.js(4 hunks)src/vald/v1/vald/remove_pb.grpc-client.d.ts(4 hunks)src/vald/v1/vald/remove_pb.grpc-client.js(4 hunks)src/vald/v1/vald/search_pb.grpc-client.d.ts(9 hunks)src/vald/v1/vald/search_pb.grpc-client.js(13 hunks)src/vald/v1/vald/update_pb.grpc-client.d.ts(3 hunks)src/vald/v1/vald/update_pb.grpc-client.js(4 hunks)src/vald/v1/vald/upsert_pb.grpc-client.d.ts(3 hunks)src/vald/v1/vald/upsert_pb.grpc-client.js(4 hunks)
💤 Files with no reviewable changes (2)
- src/vald/v1/vald/index_pb.grpc-client.js
- src/vald/v1/vald/index_pb.grpc-client.d.ts
✅ Files skipped from review due to trivial changes (2)
- src/vald/v1/vald/flush_pb.d.ts
- src/google/protobuf/descriptor_pb.js
🧰 Additional context used
🪛 Biome (1.9.4)
src/vald/v1/vald/flush_pb.grpc-client.js
[error] 22-23: Redundant use strict directive.
The entire contents of JavaScript modules are automatically in strict mode, with no statement needed to initiate it.
Safe fix: Remove the redundant use strict directive.
(lint/suspicious/noRedundantUseStrict)
src/vald/v1/vald/flush_pb.js
[error] 22-23: Redundant use strict directive.
The entire contents of JavaScript modules are automatically in strict mode, with no statement needed to initiate it.
Safe fix: Remove the redundant use strict directive.
(lint/suspicious/noRedundantUseStrict)
🔇 Additional comments (101)
src/google/protobuf/descriptor_pb.d.ts (2)
1008-1009: Good clarification on CType usage.
The updated comment clearly states that the ctype option is only implemented for non-repeated fields of type "bytes," which helps developers set appropriate expectations.
2023-2023: Grammar correction confirmed.
Changing “relyed” to “relied on” is properly handled.
src/vald/v1/vald/index.js (2)
3-3: New export for flush: Looks good
Exporting “flush” via require("./flush_pb") aligns with the existing naming pattern (e.g. filter, insert, etc.). No additional concerns.
4-4: New export for flush_grpc: Also consistent
Introducing the gRPC client export “flush_grpc” mirrors other gRPC exports (e.g. filter_grpc, insert_grpc, etc.) and follows consistent naming.
src/vald/v1/vald/index.d.ts (2)
3-4: Flush imports match the established pattern
Imports for flush and flush_grpc mirror existing naming conventions for other modules (e.g. filter, insert, remove). Good consistency.
22-23: Flush bindings added to exports
Including flush and flush_grpc in the default export object ensures the flush functionality is discoverable in downstream TypeScript projects.
src/vald/v1/vald/flush_pb.grpc-client.d.ts (1)
1-58: New gRPC Flush client interface and class look correct
The multiple overloads for the flush method accommodate diverse usage patterns (metadata, options, callbacks). Everything appears aligned with established gRPC patterns.
src/vald/v1/vald/insert_pb.grpc-client.js (1)
61-61: Confirm completeness of method documentation.
By shortening the explanation for this method, consider verifying that critical information, such as usage examples or error expectations, is accessible in other reference documentation.
src/vald/v1/vald/upsert_pb.grpc-client.js (2)
51-51: Overview comment alignment.
The updated overview is aligned with the narrower scope of the service explanation. This is clear; just ensure any advanced configuration or error-handling references remain documented if required.
61-61: Method usage details.
Concise method documentation helps readability. Double-check that the removal of errata doesn’t obscure important return/error states.
src/vald/v1/vald/update_pb.grpc-client.js (3)
51-51: Streamlined documentation for UpdateClient.
This minimal overview is clear. Confirm that other references or advanced usage guides remain accessible.
61-61: Partial detail removal verification.
Ensure that removing extensive status code info does not hinder debugging. A separate doc or error reference table might be beneficial if not already present.
79-79: Multiple updates in a single request.
The doc is concise and direct. Confirm older error-handling steps remain accessible if they contained crucial usage info.
src/vald/v1/vald/remove_pb.grpc-client.js (2)
51-51: Concise RemoveClient overview.
The simpler overview better matches the pattern across the codebase. Keep verifying if the previously removed details need separate references.
70-70: Remove by timestamp.
The new doc string is concise. If the timestamp logic has complexities, consider referencing them in deeper docs for advanced troubleshooting.
src/vald/v1/vald/object_pb.grpc-client.js (4)
51-51: Your doc simplification is good.
The updated class-level comment succinctly describes the core function (fetching indexed vectors). This is .
61-61: Concise method description.
Streamlining "A method to check whether a specified ID is indexed or not" is well-aligned with the simplified documentation style.
70-70: Minimal doc for getting a vector.
The condensed comment still conveys the essential purpose. No issues here.
79-79: Brevity in describing bidirectional streaming.
The reduced verbosity is consistent with other changes.
src/vald/v1/vald/insert_pb.grpc-client.d.ts (8)
32-32: Clear and succinct class-level summary.
"Insert service provides ways to add new vectors." is direct and helpful.
38-38: Precise single-vector insertion doc.
"A method to add a new single vector." is suitably concise.
47-47: StreamInsert documentation is concise.
"A method to add new multiple vectors by bidirectional streaming." is acceptable.
54-54: MultiInsert overview is streamlined.
"A method to add new multiple vectors in a single request." is clear.
64-64: Duplicate short summary at class level.
Repeating "Insert service provides ways to add new vectors." is consistent with the interface-level comment.
72-72: Insert method doc remains clear.
Retaining "A method to add a new single vector." focuses on core utility.
78-78: StreamInsert usage is well described.
Sticking to concise phrasing helps keep the docs manageable.
84-84: MultiInsert doc matches usage.
No issues found; the shorter explanation is consistent with other doc changes.
src/vald/v1/vald/upsert_pb.grpc-client.d.ts (8)
32-32: Upsert service summary is succinct.
"Upsert service provides ways to insert/update vectors." effectively captures the service purpose.
38-38: Upsert doc is concise.
"A method to insert/update a vector." is straightforward and user-friendly.
47-47: StreamUpsert doc adheres to simpler style.
"A method to insert/update multiple vectors by bidirectional streaming." is a suitable summary.
54-54: MultiUpsert doc addresses batch logic.
"A method to insert/update multiple vectors in a single request." is neatly stated.
64-64: Consistent short summary at class level.
Repeating the overarching description for the Upsert service maintains clarity.
72-72: Upsert doc for class-level method is fine.
No concerns; the content is consistent and correct.
78-78: StreamUpsert doc for class method is good.
No extraneous detail; well-aligned with the simplified approach.
84-84: MultiUpsert doc for class completes consistency.
All references to multi operations are well-harmonized.
src/vald/v1/vald/update_pb.grpc-client.d.ts (8)
33-33: Update service summary is concise.
"Update service provides ways to update indexed vectors." is direct.
39-39: Doc for single vector update is valid.
"A method to update an indexed vector." is clear enough.
48-48: StreamUpdate doc is similarly streamlined.
"A method to update multiple indexed vectors by bidirectional streaming." is apt.
55-55: MultiUpdate doc clarifies batch usage.
"A method to update multiple indexed vectors in a single request." is satisfactory.
74-74: Class-level summary remains consistent
Repeating "Update service provides ways to update indexed vectors." ensures clarity.
82-82: Doc for update method (class-level) is good.
Retaining just the essential details is helpful.
88-88: Class-level StreamUpdate doc is aligned.
No issues found. The shorter statement matches the new doc style.
94-94: Class-level MultiUpdate doc is consistent.
The final doc change retains the emphasis on batch updates.
src/vald/v1/vald/remove_pb.grpc-client.d.ts (1)
33-33: Ensure consistency in service description.
Currently reads "Remove service provides ways to remove indexed vectors." This is concise, but confirm that it aligns with other services' doc style, such as "Filter service provides …," to maintain uniform documentation.
src/vald/v1/vald/object_pb.grpc-client.d.ts (3)
35-35: Short, clear overview.
"Object service provides ways to fetch indexed vectors." is concise and consistent with other service docs.
91-91: Exists method doc is consistent.
The doc matches the usage from line 41. Having the same wording in class and interface fosters consistency.
97-97: Consistent and brief doc.
"A method to fetch a vector" is straightforward. Confirm that usage of doc matches actual method capabilities, e.g., returning partial data or full objects.
src/vald/v1/vald/filter_pb.grpc-client.js (2)
51-51: Filter service doc is consistent with other services.
The statement "Filter service provides ways to connect to Vald through filter" is correct and concise.
79-79: Streaming references.
“A method to search object by bidirectional streaming” is consistent, but confirm any limitations (e.g., message size).
src/vald/v1/vald/search_pb.grpc-client.js (1)
51-51: Clear and concise.
"Search service provides ways to search indexed vectors." is consistent with the naming in other services, well done.
src/vald/v1/vald/search_pb.grpc-client.d.ts (26)
34-34: Simplified service description looks good
This concise docstring helps clarify the Search service functionality.
40-40: Docstring alignment
"A method to search indexed vectors by a raw vector." is concise and consistent with the function's name.
49-49: Docstring alignment
"A method to search indexed vectors by ID." aligns well with the searchByID functionality.
58-58: Docstring alignment
"A method to search indexed vectors by multiple vectors." is concise and maintains clarity.
65-65: Docstring alignment
"A method to search indexed vectors by multiple IDs." succinctly conveys the method's purpose.
72-72: Docstring alignment
"A method to search indexed vectors by multiple vectors in a single request." effectively highlights batch processing.
81-81: Docstring alignment
"A method to search indexed vectors by multiple IDs in a single request." is clear and helpful.
90-90: Docstring alignment
"A method to linear search indexed vectors by a raw vector." is concise and accurate.
99-99: Docstring alignment
"A method to linear search indexed vectors by ID." remains concise and correct.
108-108: Docstring alignment
"A method to linear search indexed vectors by multiple vectors." clarifies multi-vector streaming.
115-115: Docstring alignment
"A method to linear search indexed vectors by multiple IDs." succinctly conveys the multi-ID functionality.
122-123: Docstring alignment
"A method to linear search indexed vectors by multiple vectors in a single request." is straightforward.
132-133: Docstring alignment
"A method to linear search indexed vectors by multiple IDs in a single request." remains consistent with the naming.
143-143: Simplified service description
This doc clarifies the SearchClient class usage.
151-151: Docstring alignment
Matches the earlier interface doc for searching by a raw vector.
157-157: Docstring alignment
Matches the earlier interface doc for searching by ID.
163-163: Docstring alignment
Clarifies streaming searches for multiple vectors.
169-169: Docstring alignment
Clarifies streaming searches for multiple IDs.
175-175: Docstring alignment
Matches the interface doc for multiSearch.
181-181: Docstring alignment
Matches the interface doc for multiSearchByID.
187-187: Docstring alignment
"A method to linear search indexed vectors by a raw vector." remains consistent.
193-193: Docstring alignment
"A method to linear search indexed vectors by ID." is concise.
199-199: Docstring alignment
Clarifies streaming linear searches for multiple vectors.
205-205: Docstring alignment
Clarifies streaming linear searches for multiple IDs.
211-212: Docstring alignment
MultiLinearSearch doc is simplified, mirroring the interface changes.
218-219: Docstring alignment
MultiLinearSearchByID doc is equally clear, consistent with naming.
src/vald/v1/vald/filter_pb.grpc-client.d.ts (24)
41-41: Concise service overview
"Filter service provides ways to connect to Vald through filter." is straightforward.
47-47: Docstring alignment
"A method to search object." is concise and matches the method name.
56-56: Docstring alignment
"A method to search multiple objects." accurately conveys a batch operation.
65-65: Docstring alignment
"A method to search object by bidirectional streaming." clarifies streaming usage.
81-81: Docstring alignment
"Represent the streaming RPC to insert object by bidirectional streaming." effectively clarifies streaming insertion.
88-88: Docstring alignment
"A method to insert multiple objects." explicitly states multi-insertion functionality.
97-97: Docstring alignment
"A method to update object." is simple and direct.
106-106: Docstring alignment
"A method to update object by bidirectional streaming." clarifies usage.
113-113: Docstring alignment
"A method to update multiple objects." suits batch updates.
122-122: Docstring alignment
"A method to upsert object." is succinct and consistent.
131-131: Docstring alignment
"A method to upsert object by bidirectional streaming." clarifies streaming usage.
138-138: Docstring alignment
"A method to upsert multiple objects." is consistent with other multi methods.
148-148: Concise service overview
Again, "Filter service provides ways to connect to Vald through filter." for the class doc.
156-156: Docstring alignment
"A method to search object." remains consistent with the interface doc.
162-162: Docstring alignment
"A method to search multiple objects." again clarifies the multi-search.
168-168: Docstring alignment
"A method to search object by bidirectional streaming." is consistent.
180-180: Docstring alignment
"Represent the streaming RPC to insert object by bidirectional streaming." clarifies usage.
186-186: Docstring alignment
"A method to insert multiple objects." is correct.
192-192: Docstring alignment
"A method to update object." is straightforward.
198-198: Docstring alignment
"A method to update object by bidirectional streaming." clarifies usage.
204-204: Docstring alignment
"A method to update multiple objects." remains consistent.
210-210: Docstring alignment
"A method to upsert object." is succinct.
216-216: Docstring alignment
"A method to upsert object by bidirectional streaming." clarifies usage.
222-222: Docstring alignment
"A method to upsert multiple objects." is consistent with other multi methods.
Makefile (1)
47-47: New flush.proto added
Adding "v1/vald/flush.proto" to the PROTOS list ensures the new flush service is built as part of the standard generation process.
SSIA
Summary by CodeRabbit
New Features
Flushservice with methods for flushing indexed vectors.upsertoperation, allowing for insertion and updating of vectors.Documentation
update,insert, andremove.Bug Fixes