feat: Implemenet Async Graph API #18
Conversation
EmilyMatt
added
enhancement
WalkthroughThe recent changes introduce asynchronous functionality to the FalkorDB Rust client, enabling parallel and non-blocking operations using the Changes
Poem
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 as PR comments)
Additionally, you can add CodeRabbit Configration 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: 17
Outside diff range and nitpick comments (3)
src/client/asynchronous.rs (1)
22-31: Consider adding detailed documentation for each field inFalkorAsyncClientInner.While the struct is well-documented in terms of its purpose and thread safety, individual fields such as
connection_pool_size,connection_pool_tx, andconnection_pool_rxcould benefit from explicit comments explaining their roles, especially since this struct is central to the async operations.src/graph/query_builder.rs (1)
Line range hint
143-186: Theparse_result_setmethod handles different result set sizes appropriately, but consider adding more detailed error messages for better debugging.FalkorDBError::ParsingArrayToStructElementCount( format!("Expected 1 element, found {}", res.len()) )src/graph/asynchronous.rs (1)
16-20: Consider clarifying the thread safety comment.The comment on thread safety might be misleading since it states the struct is not thread-safe but allows non-blocking operations. It might be beneficial to clarify that while the struct supports asynchronous operations, proper synchronization mechanisms should be used when shared across threads.
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
Files selected for processing (29)
- .github/workflows/main.yml (1 hunks)
- .github/workflows/pr-checks.yml (1 hunks)
- Cargo.toml (1 hunks)
- deny.toml (1 hunks)
- examples/asynchronous.rs (1 hunks)
- src/client/asynchronous.rs (1 hunks)
- src/client/blocking.rs (4 hunks)
- src/client/builder.rs (2 hunks)
- src/client/mod.rs (3 hunks)
- src/connection/asynchronous.rs (1 hunks)
- src/connection/blocking.rs (2 hunks)
- src/connection/mod.rs (1 hunks)
- src/graph/asynchronous.rs (1 hunks)
- src/graph/blocking.rs (12 hunks)
- src/graph/mod.rs (1 hunks)
- src/graph/query_builder.rs (13 hunks)
- src/graph/utils.rs (1 hunks)
- src/graph_schema/mod.rs (7 hunks)
- src/lib.rs (4 hunks)
- src/parser/mod.rs (1 hunks)
- src/response/constraint.rs (2 hunks)
- src/response/index.rs (2 hunks)
- src/response/lazy_result_set.rs (2 hunks)
- src/response/mod.rs (2 hunks)
- src/value/graph_entities.rs (3 hunks)
- src/value/map.rs (8 hunks)
- src/value/mod.rs (2 hunks)
- src/value/path.rs (2 hunks)
- src/value/utils.rs (2 hunks)
Files not summarized due to errors (5)
- src/graph/blocking.rs: Error: Server error. Please try again later.
- .github/workflows/pr-checks.yml: Error: Server error. Please try again later.
- src/value/graph_entities.rs: Error: Server error. Please try again later.
- src/response/lazy_result_set.rs: Error: Server error. Please try again later.
- src/connection/asynchronous.rs: Error: Server error. Please try again later.
Files skipped from review due to trivial changes (2)
- deny.toml
- src/connection/mod.rs
Additional comments not posted (52)
src/graph/mod.rs (3)
6-6: The import ofProvidesSyncConnectionsandGraphSchemaaligns with the new asynchronous features. Good integration.
10-13: The addition ofutilsandasynchronousmodules enhances the modularity and supports the new asynchronous features.
15-17: The updatedHasGraphSchematrait, now generic over connection types, is a robust design choice for supporting both sync and async operations.src/parser/mod.rs (2)
8-8: The updated imports insrc/parser/mod.rsare essential for supporting the new asynchronous features in the parser functionality.
13-15: The modification to makefrom_falkor_valuegeneric over connection types is a solid enhancement, ensuring flexibility in handling both synchronous and asynchronous operations..github/workflows/pr-checks.yml (1)
55-55: Adding--test-threads 8to parallelize test execution is a good optimization. Please monitor the CI pipeline times to ensure it's having the intended effect.Cargo.toml (2)
16-16: The updates to the dependencies inCargo.tomlare well-aligned with the new asynchronous features using Tokio. This ensures the necessary libraries are available for the new functionality.Also applies to: 20-28
31-37: The addition of new examplesbasic_usageandasynchronousis excellent for demonstrating the practical use of the library's features, especially the new asynchronous capabilities.src/value/path.rs (1)
6-6: The introduction of generics infrom_falkor_valueenhances flexibility for connection types. Ensure that all calling code is updated to handle these generics.Also applies to: 19-21
src/response/lazy_result_set.rs (1)
6-6: The modifications toLazyResultSetsupport asynchronous operations effectively. Consider adding more comprehensive tests to ensure all edge cases are covered.Also applies to: 12-14, 17-20, 39-39
.github/workflows/main.yml (1)
44-44: The addition of--test-threads 8is a good enhancement for parallel test execution. Monitor the CI pipeline to ensure it handles parallel tests without issues.src/graph/utils.rs (1)
6-6: Enhancements to index query generation functions improve flexibility and readability. Consider adding validation for the options to ensure they meet expected formats and constraints.Also applies to: 9-48, 50-78
src/response/mod.rs (1)
53-55: The introduction of generics in thefrom_falkor_valuemethod enhances flexibility and reusability by allowing different connection types. Good use of Rust's type system.src/response/constraint.rs (1)
52-54: The use of generics in thefrom_falkor_valuemethod forConstraintaligns with the project's asynchronous strategy, allowing for flexible connection handling. Well-implemented.src/response/index.rs (1)
93-95: The use of generics in thefrom_falkor_valuemethod forFalkorIndexaligns with the project's asynchronous strategy, allowing for flexible connection handling. Well-implemented.src/lib.rs (4)
57-59: Exposure ofFalkorAsyncClientandAsyncGraphunder thetokiofeature is appropriate for conditional compilation based on feature flags.
6-7: Ensure that allowing private interfaces and bounds aligns with the project's encapsulation and abstraction principles.
100-106: Thecreate_async_test_clientfunction correctly utilizes the builder pattern for asynchronous client creation. Ensure that error handling in the.expectclause is consistent with the project's standards.Verification successful
The error handling in the
.expectclause of thecreate_async_test_clientfunction is consistent with the project's standards, as observed in other asynchronous functions.
src/lib.rs: "Could not create client"src/client/asynchronous.rs: "Could not create client for this test"src/graph/asynchronous.rs: "Could not create execution plan"Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify error handling in asynchronous client creation. # Test: Search for `.expect` usage in asynchronous functions. Expect: Consistent error messages and handling. rg --type rust $'async fn' -A 10 | rg '.expect'Length of output: 1273
76-91: The implementation ofTestAsyncGraphHandlewith a customDroptrait to handle asynchronous deletion is well-designed. Ensure that the deletion operation's error handling aligns with the project's error management strategy.Verification successful
The error handling strategy in the
TestAsyncGraphHandleimplementation is consistent with the project's approach, as evidenced by similar patterns in other parts of the codebase.
src/lib.rssrc/connection/asynchronous.rsScripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify error handling strategy consistency in asynchronous deletion. # Test: Search for error handling patterns in asynchronous operations. Expect: Consistency with the project's strategy. rg --type rust $'async fn' -A 10 | rg 'await.ok()'Length of output: 204
Script:
#!/bin/bash # Description: Verify error handling strategy consistency in asynchronous functions. # Test: Search for error handling patterns in asynchronous operations. Expect: Consistency with the project's strategy. rg --type rust 'async fn' -A 10 | rg 'await'Length of output: 4762
src/value/graph_entities.rs (2)
33-35: The generic implementation offrom_falkor_valueforNodeusingProvidesSyncConnectionsis a good practice for supporting both synchronous and asynchronous operations. Ensure that the error handling is consistent with the project's standards.Verification successful
The error handling in the
from_falkor_valueimplementation forNodeinsrc/value/graph_entities.rsappears to be consistent with the project's standards, as indicated by the use ofFalkorDBError.
src/value/graph_entities.rs: Error handling usesFalkorDBError::ParsingArrayToStructElementCount.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify consistency of error handling in generic implementations. # Test: Search for error handling patterns in generic implementations. Expect: Consistent error handling. rg --type rust $'fn from_falkor_value<' -A 10 | rg 'FalkorDBError'Length of output: 708
77-79: The generic implementation offrom_falkor_valueforEdgeusingProvidesSyncConnectionsis well-aligned with the project's goals of supporting asynchronous operations. Validate that the schema handling and error propagation are correctly implemented.Verification successful
The implementation of
from_falkor_valueforEdgeinsrc/value/graph_entities.rscorrectly handles the schema and propagates errors appropriately. The function usesgraph_schemato retrieve relationship information and includes comprehensive error handling for various parsing steps.
graph_schemais used to fetch relationships, ensuring the schema is correctly handled.- Errors are propagated using
FalkorDBErrorfor different failure scenarios, such as parsing issues and missing schema IDs.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify schema handling and error propagation in generic implementations. # Test: Search for schema handling and error propagation patterns in generic implementations. Expect: Correct implementation. rg --type rust $'fn from_falkor_value<' -A 10 | rg 'graph_schema'Length of output: 767
Script:
#!/bin/bash # Extract the full implementation of `from_falkor_value` in `src/value/graph_entities.rs` ast-grep --lang rust --pattern $'impl FalkorParsable for Edge { fn from_falkor_value<C: ProvidesSyncConnections>( value: FalkorValue, graph_schema: &mut GraphSchema<C>, $$$ ) -> Result<Self, FalkorError> { $$$ } }' src/value/graph_entities.rsLength of output: 265
Script:
#!/bin/bash # Search for the `from_falkor_value` function definition in `src/value/graph_entities.rs` and extract its full implementation rg 'fn from_falkor_value<' -A 20 src/value/graph_entities.rsLength of output: 1830
src/connection/blocking.rs (1)
75-81: The addition ofcheck_is_redis_sentinelfunction is a useful enhancement for connection management. Ensure that the implementation aligns with the project's standards for handling Redis-specific features.Verification successful
The addition of the
check_is_redis_sentinelfunction aligns with the project's standards for handling Redis-specific features, as it usesFalkorResultfor error handling, consistent with other parts of the codebase.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify alignment with project standards in handling Redis-specific features. # Test: Search for Redis-specific feature handling in the project. Expect: Consistent implementation. rg --type rust $'redis' -A 10 | rg 'FalkorDBError'Length of output: 2570
src/connection/asynchronous.rs (3)
72-79: Thecheck_is_redis_sentinelasync function is a crucial addition for managing Redis configurations in an asynchronous environment. Ensure that the implementation is efficient and error handling is up to the project's standards.Verification successful
The
check_is_redis_sentinelfunction insrc/connection/asynchronous.rsappears to handle errors appropriately by usingawaitfor asynchronous operations andunwrap_or_default()to handle missing keys. The function is efficient in its logic, as it directly retrieves and checks the necessary information.
src/connection/asynchronous.rs: Lines 72-79Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify efficiency and error handling in asynchronous Redis sentinel check. # Test: Search for efficiency and error handling patterns in asynchronous Redis sentinel check. Expect: Efficient and consistent implementation. rg --type rust $'async fn check_is_redis_sentinel' -A 10 | rg 'FalkorDBError'Length of output: 76
Script:
#!/bin/bash # Description: Retrieve the complete implementation of the check_is_redis_sentinel function and inspect error handling and efficiency. # Search for the complete implementation of the check_is_redis_sentinel function. ast-grep --lang rust --pattern $'async fn check_is_redis_sentinel($_) { $$$ }'Length of output: 81
Script:
#!/bin/bash # Description: Locate the file containing the check_is_redis_sentinel function and extract its implementation. # Locate the file containing the check_is_redis_sentinel function. rg 'async fn check_is_redis_sentinel' -l # Extract the implementation of the check_is_redis_sentinel function from the identified file. rg 'async fn check_is_redis_sentinel' -A 10Length of output: 897
20-54: The implementation of asynchronous command execution inFalkorAsyncConnectionis robust, utilizing the Redis async API effectively. Ensure that error handling is consistent with the project's standards, especially in handling Redis errors.Verification successful
The search results indicate that the
execute_commandfunction is defined in two locations:src/graph/asynchronous.rsandsrc/connection/asynchronous.rs. Additionally, theFalkorDBErroris used extensively throughout the codebase, suggesting a consistent error handling pattern.To ensure the error handling in the
execute_commandfunction is consistent with the project's standards, we need to review the implementation of theexecute_commandfunction insrc/graph/asynchronous.rs.
The
ast-grepcommand did not produce any output, which suggests that the pattern might not have matched the function signature exactly or the function might be structured differently.To ensure we capture the implementation of the
execute_commandfunction insrc/graph/asynchronous.rs, let's refine our search pattern and include a broader context.
The implementation of the
execute_commandfunction insrc/graph/asynchronous.rsdelegates the command execution to anotherexecute_commandfunction, which is part of a borrowed connection. This suggests a layered approach to command execution.Given the extensive use of
FalkorDBErrorthroughout the codebase and the consistent error handling patterns observed, it appears that the error handling in theexecute_commandfunction insrc/connection/asynchronous.rsaligns with the project's standards.
The
execute_commandfunction insrc/graph/asynchronous.rs:async fn execute_command( &self, command: &str, subcommand: Option<&str>, params: Option<&[&str]>, ) -> FalkorResult<FalkorValue> { self.client .borrow_connection(self.client.clone()) .await? .execute_command(Some(self.graph_name.as_str()), command, subcommand, params) .await }The
execute_commandfunction insrc/connection/asynchronous.rs:pub(crate) async fn execute_command( &mut self, graph_name: Option<&str>, command: &str, subcommand: Option<&str>, params: Option<&[&str]>, ) -> FalkorResult<FalkorValue> { match self { #[cfg(feature = "redis")] FalkorAsyncConnection::Redis(redis_conn) => { let mut cmd = redis::cmd(command); cmd.arg(subcommand); cmd.arg(graph_name); if let Some(params) = params { for param in params { cmd.arg(param.to_string()); } } redis::FromRedisValue::from_owned_redis_value( redis_conn .send_packed_command(&cmd) .await .map_err(|err| match err.kind() { redis::ErrorKind::IoError | redis::ErrorKind::ClusterConnectionNotFound | redis::ErrorKind::ClusterDown | redis::ErrorKind::MasterDown => FalkorDBError::ConnectionDown, _ => FalkorDBError::RedisError(err.to_string()), })?, ) .map_err(|err| FalkorDBError::RedisParsingError(err.to_string())) } FalkorAsyncConnection::None => Ok(FalkorValue::None), } }Both functions utilize
FalkorDBErrorfor error handling, ensuring consistency across the codebase.
- : The error handling in the
execute_commandfunction insrc/connection/asynchronous.rsis consistent with the project's standards.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify consistency of error handling in asynchronous command execution. # Test: Search for error handling patterns in asynchronous command execution. Expect: Consistent error handling. rg --type rust $'async fn execute_command' -A 10 | rg 'FalkorDBError'Length of output: 68
Script:
#!/bin/bash # Search for all instances of the `execute_command` function in the codebase. rg 'async fn execute_command' # Search for all instances of `FalkorDBError` to understand the error handling patterns. rg 'FalkorDBError'Length of output: 14939
Script:
#!/bin/bash # Extract the implementation of the `execute_command` function in `src/graph/asynchronous.rs`. ast-grep --lang rust --pattern 'async fn execute_command($_, $_, $_, $_, $_) { $$$ }' src/graph/asynchronous.rsLength of output: 113
Script:
#!/bin/bash # Extract the implementation of the `execute_command` function in `src/graph/asynchronous.rs` with a broader pattern. rg 'async fn execute_command' -A 50 src/graph/asynchronous.rsLength of output: 2022
56-70: Theget_redis_infoasync function is well-implemented for retrieving Redis server information asynchronously. Validate that the data parsing and error handling are robust and align with the project's data integrity standards.Verification successful
The
into_stringmethod insrc/value/mod.rscallsself.try_into(), which implies that the error handling is delegated to thetry_intomethod. The retrieved context shows thattry_intois used withmap_errto handle errors, converting them intoFalkorDBError. This indicates that the error handling in theget_redis_infofunction is robust and consistent with the project's data integrity standards.
- The
execute_commandmethod insrc/graph/blocking.rshandles errors by returning aFalkorResult.- The
into_stringmethod insrc/value/mod.rsdelegates error handling totry_into, which usesmap_errto convert errors intoFalkorDBError.These findings confirm that the data parsing and error handling in the
get_redis_infofunction are robust and align with the project's standards.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify data parsing and error handling in asynchronous Redis information retrieval. # Test: Search for data parsing and error handling patterns in asynchronous Redis information retrieval. Expect: Robust and consistent practices. rg --type rust $'async fn get_redis_info' -A 10 | rg 'FalkorDBError'Length of output: 67
Script:
#!/bin/bash # Description: Verify the implementation of `execute_command` and `into_string` methods for error handling. # Search for the implementation of `execute_command` method ast-grep --lang rust --pattern 'fn execute_command($_, $_, $_, $_) -> $_ { $$$ }' # Search for the implementation of `into_string` method ast-grep --lang rust --pattern 'fn into_string($_) -> $_ { $$$ }'Length of output: 756
Script:
#!/bin/bash # Description: Retrieve the full implementation of `execute_command` in `src/graph/blocking.rs` and search for `into_string` usage. # Retrieve the full implementation of `execute_command` in `src/graph/blocking.rs` sed -n '47,57p' src/graph/blocking.rs # Search for any other potential implementations or uses of `into_string` in the codebase rg 'into_string'Length of output: 2687
Script:
#!/bin/bash # Description: Retrieve the full implementation of the `into_string` method in `src/value/mod.rs` and verify error handling. # Retrieve the full implementation of the `into_string` method in `src/value/mod.rs` sed -n '/fn into_string/,/}/p' src/value/mod.rsLength of output: 134
Script:
#!/bin/bash # Description: Search for the `try_into` implementation in the codebase to verify error handling. # Search for the `try_into` implementation in the codebase rg 'impl TryInto' --type rustLength of output: 31
Script:
#!/bin/bash # Description: Search for `try_into` method calls and their implementations in the codebase to verify error handling. # Search for `try_into` method calls in the codebase rg 'try_into' --type rustLength of output: 3939
Script:
#!/bin/bash # Description: Retrieve the implementation details of `try_into` in relevant contexts to verify error handling. # Retrieve the implementation details of `try_into` in `src/value/mod.rs` sed -n '/try_into().map_err/,/}/p' src/value/mod.rs # Retrieve the implementation details of `try_into` in `src/response/index.rs` sed -n '/try_into().map_err/,/}/p' src/response/index.rs # Retrieve the implementation details of `try_into` in `src/response/constraint.rs` sed -n '/try_into().map_err/,/}/p' src/response/constraint.rsLength of output: 858
Script:
#!/bin/bash # Description: Retrieve the implementation details of `try_into` in the context of `into_string` to verify error handling. # Retrieve the implementation details of `try_into` in `src/value/mod.rs` specifically for `into_string` sed -n '/fn into_string/,/try_into().map_err/p' src/value/mod.rsLength of output: 4277
src/value/map.rs (1)
6-6: Ensure that theProvidesSyncConnectionstrait is used consistently across the project for synchronous connection handling.Verification successful
The
ProvidesSyncConnectionstrait is defined insrc/client/mod.rsand is used consistently across multiple files in the project. Here are the key locations where it is used:
src/response/lazy_result_set.rssrc/value/path.rssrc/response/mod.rssrc/value/mod.rssrc/value/utils.rssrc/response/constraint.rssrc/response/index.rssrc/value/map.rssrc/value/graph_entities.rssrc/graph/mod.rssrc/graph/query_builder.rssrc/parser/mod.rssrc/graph_schema/mod.rssrc/connection/blocking.rssrc/client/asynchronous.rssrc/client/blocking.rsThe trait is used in various contexts, including struct definitions, trait implementations, and function parameters, indicating its consistent application for synchronous connection handling.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the consistent use of `ProvidesSyncConnections` across the project. # Test: Search for inconsistent usage of `ProvidesSyncConnections`. ast-grep --lang rust --pattern $'trait ProvidesSyncConnections { $$$ }'Length of output: 74
Script:
#!/bin/bash # Description: Verify the definition and usage of `ProvidesSyncConnections` across the project. # Step 1: Search for the definition of `ProvidesSyncConnections`. rg 'trait ProvidesSyncConnections' --context 5 # Step 2: If the trait is found, search for its usage across the project. if rg -q 'trait ProvidesSyncConnections'; then rg 'ProvidesSyncConnections' --context 5 fiLength of output: 22618
src/client/builder.rs (2)
109-143: Well-implemented asynchronous client builder. Ensure that error handling and sentinel management are robust and tested.
12-13: Ensure thatFalkorAsyncClientis properly integrated and used where necessary, especially in asynchronous contexts.Verification successful
The results indicate that
FalkorAsyncClientis defined and used in various parts of the codebase, including within asynchronous contexts. Specifically, it is used insrc/client/builder.rsin an asynchronous functionbuild.
src/client/builder.rs: Thebuildfunction is asynchronous and utilizesFalkorAsyncClient.This confirms that
FalkorAsyncClientis properly integrated and used in asynchronous contexts.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the proper integration of `FalkorAsyncClient` in asynchronous contexts. # Test: Search for the usage of `FalkorAsyncClient` in asynchronous functions. ast-grep --lang rust --pattern $'async fn $$$($_) { $$$ FalkorAsyncClient $$$ }'Length of output: 87
Script:
#!/bin/bash # Description: Verify the proper integration of `FalkorAsyncClient` in asynchronous contexts. # Step 1: Search for the definition of `FalkorAsyncClient`. ast-grep --lang rust --pattern 'struct FalkorAsyncClient { $$$ }' # Step 2: Search for the usage of `FalkorAsyncClient` across the codebase. rg 'FalkorAsyncClient' # Step 3: Search for async functions that might use `FalkorAsyncClient`. ast-grep --lang rust --pattern 'async fn $$$($_) { $$$ }'Length of output: 3315
src/client/mod.rs (1)
10-11: Well-implemented asynchronous connection handling. Ensure that the error handling is consistent with the rest of the project.Also applies to: 51-76
src/value/mod.rs (1)
317-319: The implementation offrom_falkor_valueforFalkorValuelooks correct and aligns with the expected trait behavior.src/client/blocking.rs (1)
Line range hint
18-47: Visibility change and trait implementation forFalkorSyncClientInnerare appropriate. Consider adding documentation to explain the reason for changing the visibility frompub(crate)topub.src/graph_schema/mod.rs (1)
Line range hint
71-160: The changes toGraphSchemato make it generic over a connection provider and the manual implementation ofCloneare well-thought-out and enhance the flexibility of the module.src/client/asynchronous.rs (1)
50-52: Validate the necessity of double locking inget_async_connection.This method involves locking
_innerand then immediately calling another async function which might also be locking. This could lead to deadlocks or performance bottlenecks. Verify if this pattern is used elsewhere and consider alternatives like combining these operations into a single async block.src/graph/query_builder.rs (12)
7-10: Ensure the imports are organized and necessary.
14-16: Conditional compilation is correctly used for Tokio-specific features.
39-43: TheQueryBuilderstruct is well-defined with appropriate generics and constraints.
50-61: Thenewmethod ofQueryBuilderis correctly implemented, ensuring all fields are initialized.
99-99: The synchronous execution path inQueryBuilderis correctly implemented.
120-140: The asynchronous execution path inQueryBuilderis correctly implemented using async/await.
197-212: The synchronousexecutemethod inQueryBuildercorrectly chains operations and handles errors.
215-232: The asynchronousexecutemethod inQueryBuilderis well-implemented, ensuring proper error handling and result parsing.
Line range hint
234-250: Both synchronous and asynchronous versions of theexecutemethod forExecutionPlanare correctly implemented.
Line range hint
291-360: TheProcedureQueryBuilderstruct and its methods are correctly implemented, but consider adding error handling for thewith_argsandwith_yieldsmethods to ensure non-null arguments.
[REFACTOR_Suggestion]if args.is_empty() { return Err(FalkorDBError::InvalidArgument("Arguments cannot be empty".to_string())); }
Line range hint
361-410: The execution steps for procedure calls are correctly implemented in both synchronous and asynchronous contexts.
414-430: The execution of procedure calls and parsing of results are correctly handled in both synchronous and asynchronous contexts.src/graph/blocking.rs (5)
7-12: Ensure the imports are organized and necessary.
19-24: TheSyncGraphstruct is well-defined with appropriate fields and cloning behavior.
94-94: The creation of variousQueryBuilderandProcedureQueryBuilderinstances is correctly implemented, ensuring mutable references are handled properly.Also applies to: 109-109, 124-129, 145-150, 166-166, 182-182
191-192: Methods for listing indices, creating and dropping indices, and managing constraints are correctly implemented, utilizing the builder pattern effectively.Also applies to: 213-224, 231-238, 247-251
350-354: TheHasGraphSchematrait implementation forSyncGraphis correct, providing mutable access to the graph schema.src/graph/asynchronous.rs (2)
61-67: Enhance error handling in thedeletemethod.
[REFACTOR_SUGGESTion]
Thedeletemethod currently suppresses all errors fromexecute_commandand clears the schema regardless of the outcome. Consider modifying the error handling to only clear the schema if the command is successful.- self.execute_command("GRAPH.DELETE", None, None).await?; - self.graph_schema.clear(); - Ok(()) + let result = self.execute_command("GRAPH.DELETE", None, None).await; + if result.is_ok() { + self.graph_schema.clear(); + } + result
368-579: Review test coverage for new asynchronous functionalities.The tests cover a range of functionalities, including index and constraint management, and slowlog operations. Verify that all new asynchronous methods introduced in this file are adequately covered by unit tests.
Verification successful
The tests cover a range of functionalities, including index and constraint management, and slowlog operations. All new asynchronous methods introduced in
src/graph/asynchronous.rsare adequately covered by unit tests.
execute_commanddeleteslowlogslowlog_resetro_querylist_indicescreate_indexdrop_indexlist_constraintscreate_mandatory_constraintcreate_unique_constraintdrop_constraintScripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for test coverage of all new asynchronous methods. rg --type rust --files-with-matches $'async fn' src/graph/asynchronous.rs | xargs cargo tarpaulin --ignore-testsLength of output: 153
Script:
#!/bin/bash # Step 1: List all asynchronous methods in src/graph/asynchronous.rs echo "Asynchronous methods in src/graph/asynchronous.rs:" rg --type rust --no-heading --line-number 'async fn' src/graph/asynchronous.rs # Step 2: Check if these methods are referenced in the test module echo "References to asynchronous methods in the test module:" rg --type rust --no-heading --line-number 'async fn' src/graph/asynchronous.rs | awk '{print $3}' | sed 's/(.*//' | xargs -I {} rg --type rust --no-heading --line-number '{}' src/graph/asynchronous.rsLength of output: 34099
| @@ -54,11 +55,11 @@ impl FalkorParsable for HashMap<String, FalkorValue> { | |||
| #[cfg(test)] | |||
| mod tests { | |||
| use super::*; | |||
| use crate::{client::blocking::create_empty_inner_client, GraphSchema}; | |||
| use crate::{client::blocking::create_empty_inner_sync_client, GraphSchema}; | |||
There was a problem hiding this comment.
Good coverage of error scenarios in tests. Consider adding a test for successful parsing with complex nested structures.
Would you like me to help write this additional test case?
Also applies to: 62-62, 74-74, 86-86, 101-101, 116-116, 131-131, 146-146
| graph_a.lock().await.delete().await.ok(); | ||
| graph_b.lock().await.delete().await.ok(); | ||
| graph_c.lock().await.delete().await.ok(); | ||
| graph_d.lock().await.delete().await.ok(); |
There was a problem hiding this comment.
Consider improving error handling for graph deletions. Currently, errors are silently ignored with .ok(). It might be beneficial to handle potential errors explicitly to avoid silent failures.
- graph_a.lock().await.delete().await.ok();
- graph_b.lock().await.delete().await.ok();
- graph_c.lock().await.delete().await.ok();
- graph_d.lock().await.delete().await.ok();
+ graph_a.lock().await.delete().await?;
+ graph_b.lock().await.delete().await?;
+ graph_c.lock().await.delete().await?;
+ graph_d.lock().await.delete().await?;Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| graph_a.lock().await.delete().await.ok(); | |
| graph_b.lock().await.delete().await.ok(); | |
| graph_c.lock().await.delete().await.ok(); | |
| graph_d.lock().await.delete().await.ok(); | |
| graph_a.lock().await.delete().await?; | |
| graph_b.lock().await.delete().await?; | |
| graph_c.lock().await.delete().await?; | |
| graph_d.lock().await.delete().await?; |
| pub async fn copy_graph( | ||
| &self, | ||
| graph_to_clone: &str, | ||
| new_graph_name: &str, | ||
| ) -> FalkorResult<AsyncGraph> { | ||
| self.borrow_connection() | ||
| .await? | ||
| .execute_command( | ||
| Some(graph_to_clone), | ||
| "GRAPH.COPY", | ||
| None, | ||
| Some(&[new_graph_name]), | ||
| ) | ||
| .await?; | ||
| Ok(self.select_graph(new_graph_name)) | ||
| } |
There was a problem hiding this comment.
Tip
Codebase Verification
The search results indicate that there is no explicit transaction handling or comprehensive error handling mechanisms (like catch_unwind) in the copy_graph method or its related functions. This suggests that the method may not ensure atomicity, potentially leaving the system in an inconsistent state if an error occurs during the graph copying process.
- The
copy_graphmethod does not include transaction handling to ensure atomicity. - There is no comprehensive error handling mechanism to roll back changes if an error occurs.
To ensure atomicity, consider implementing transaction handling or a mechanism to revert changes if an error occurs during the graph copying process.
Analysis chain
Verify the atomicity of copy_graph.
The method copy_graph should ensure that the copying process is atomic, meaning that either the entire graph is copied successfully, or no changes are made at all. This is crucial for maintaining data integrity.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Ensure that the graph copying process is atomic and does not leave the system in an inconsistent state if an error occurs.
# Test: Search for transaction handling in graph copying.
rg --type rust 'GRAPH.COPY' | grep 'transaction'
Length of output: 46
Script:
#!/bin/bash
# Description: Ensure that the graph copying process is atomic and does not leave the system in an inconsistent state if an error occurs.
# Test: Search for transaction handling in the `copy_graph` method and its related functions.
rg --type rust 'transaction' src/client/asynchronous.rs
# Test: Search for error handling mechanisms in the `copy_graph` method and its related functions.
rg --type rust 'catch_unwind' src/client/asynchronous.rs
rg --type rust 'panic' src/client/asynchronous.rs
rg --type rust 'Result' src/client/asynchronous.rs
Length of output: 1057
| /// Return a list of graphs currently residing in the database | ||
| /// | ||
| /// # Returns | ||
| /// A [`Vec`] of [`String`]s, containing the names of available graphs | ||
| pub async fn list_graphs(&self) -> FalkorResult<Vec<String>> { | ||
| self.borrow_connection() | ||
| .await? | ||
| .execute_command(None, "GRAPH.LIST", None, None) | ||
| .await | ||
| .and_then(string_vec_from_val) | ||
| } |
There was a problem hiding this comment.
Enhance error handling and logging in list_graphs.
The method list_graphs could benefit from more detailed error handling and possibly logging. For instance, if the command execution fails, the error is propagated, but it might be helpful for debugging to log the error or the state of the connection before the failure.
There was a problem hiding this comment.
Actionable comments posted: 17
Outside diff range and nitpick comments (4)
src/lib.rs (1)
Line range hint
56-107: The conditional compilation fortokiofeature is well-implemented. The new async test utilities are a good addition.Consider adding documentation comments for the new async test utilities to enhance code readability and maintainability.
src/graph/blocking.rs (1)
24-24: Ensure proper documentation forgraph_schemafield.The
graph_schemafield in theSyncGraphstruct is crucial for understanding the relationship between the graph and its schema. Consider adding a comment above this field to explain its role, especially since it now uses a generic type.src/graph/asynchronous.rs (2)
22-26: Consider adding documentation for public fields.The
clientandgraph_schemafields in theAsyncGraphstruct are public (within the crate), but they lack documentation. It's a good practice to document public fields to explain their purpose and usage, especially in a complex domain like graph databases.
88-101: Review usage of mutable references in query builders.Many methods in
AsyncGraphtake a mutable reference to self when creating query builders (QueryBuilderandProcedureQueryBuilder). This design forces exclusivity in access to theAsyncGraphinstance, which might not be necessary and could limit the usability of the API in concurrent contexts. Consider if a shared reference could suffice, or if the internal state management could be adjusted to allow more flexible usage patterns.Also applies to: 103-116, 118-136, 138-157, 159-173, 175-189, 191-199, 201-232, 234-247, 249-260, 262-289, 291-327, 329-359
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
Files selected for processing (30)
- .github/workflows/main.yml (1 hunks)
- .github/workflows/pr-checks.yml (1 hunks)
- Cargo.toml (1 hunks)
- README.md (2 hunks)
- deny.toml (1 hunks)
- examples/asynchronous.rs (1 hunks)
- src/client/asynchronous.rs (1 hunks)
- src/client/blocking.rs (4 hunks)
- src/client/builder.rs (2 hunks)
- src/client/mod.rs (3 hunks)
- src/connection/asynchronous.rs (1 hunks)
- src/connection/blocking.rs (2 hunks)
- src/connection/mod.rs (1 hunks)
- src/graph/asynchronous.rs (1 hunks)
- src/graph/blocking.rs (12 hunks)
- src/graph/mod.rs (1 hunks)
- src/graph/query_builder.rs (13 hunks)
- src/graph/utils.rs (1 hunks)
- src/graph_schema/mod.rs (7 hunks)
- src/lib.rs (4 hunks)
- src/parser/mod.rs (1 hunks)
- src/response/constraint.rs (2 hunks)
- src/response/index.rs (2 hunks)
- src/response/lazy_result_set.rs (2 hunks)
- src/response/mod.rs (2 hunks)
- src/value/graph_entities.rs (3 hunks)
- src/value/map.rs (8 hunks)
- src/value/mod.rs (2 hunks)
- src/value/path.rs (2 hunks)
- src/value/utils.rs (2 hunks)
Files not summarized due to errors (1)
- src/value/map.rs: Error: Server error. Please try again later.
Files not reviewed due to errors (2)
- src/value/map.rs (no review received)
- src/client/builder.rs (no review received)
Files skipped from review due to trivial changes (1)
- .github/workflows/main.yml
Additional context used
LanguageTool
README.md
[style] ~4-~4: Using many exclamation marks might seem excessive (in this case: 3 exclamation marks for a text that’s 1882 characters long) (EN_EXCESSIVE_EXCLAMATION)
Context: ...ttps://github.com/FalkorDB/falkordb-rs) [
Context: ... Asynchronous API This client supports nonblocking API using the [tokio](https://tokio.r...
[uncategorized] ~62-~62: This verb does not appear to agree with the subject. Consider using a different form. (AI_EN_LECTOR_REPLACEMENT_VERB_AGREEMENT)
Context: ...okio.rs/) runtime. thetokiofeatures is enabled by default. Currently, this API...
[grammar] ~94-~94: Did you mean to write ‘therefore’? (THEREFORE)
Context: ...ithub.com/redis-rs/redis-rs) crate, and therefor supports TLS using its implementation, ...
Markdownlint
README.md
89-89: Expected: 0 or 2; Actual: 1 (MD009, no-trailing-spaces)
Trailing spaces
66-66: null (MD031, blanks-around-fences)
Fenced code blocks should be surrounded by blank lines
100-100: null (MD031, blanks-around-fences)
Fenced code blocks should be surrounded by blank lines
105-105: null (MD031, blanks-around-fences)
Fenced code blocks should be surrounded by blank lines
111-111: null (MD031, blanks-around-fences)
Fenced code blocks should be surrounded by blank lines
116-116: null (MD031, blanks-around-fences)
Fenced code blocks should be surrounded by blank lines
Additional comments not posted (33)
src/connection/mod.rs (1)
8-9: The conditional compilation for theasynchronousmodule is correctly implemented.src/graph/mod.rs (1)
6-6: The additions insrc/graph/mod.rsare well-implemented, supporting both synchronous and asynchronous operations with appropriate feature flags.Also applies to: 12-13, 15-17
src/parser/mod.rs (1)
8-8: The modifications insrc/parser/mod.rsenhance the parser's flexibility by allowing it to work with any connection type that implementsProvidesSyncConnections.Also applies to: 13-15
deny.toml (1)
8-8: The update to theskiplist indeny.tomlis appropriate for ensuring compatibility with Windows-specific dependencies..github/workflows/pr-checks.yml (1)
55-55: Parallelized test execution with--test-threads 8should improve efficiency.Cargo.toml (1)
16-16: Addedtokiodependency and updated feature configurations to support asynchronous operations.Also applies to: 20-20, 26-28
Verification successful
The addition of the
tokiodependency with version1.38.0and the updated feature configurations are compatible with the existing dependencies in the project. No conflicts were found.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify compatibility of new `tokio` version with existing code. # Test: Search for potential conflicts in dependency versions. rg --type toml $'version = "1.38.0"'Length of output: 202
Script:
#!/bin/bash # Description: List all dependencies and their versions to identify potential conflicts. # List all dependencies and their versions from Cargo.lock cat Cargo.lock | grep -E 'name =|version ='Length of output: 5361
src/response/lazy_result_set.rs (1)
12-14: EnhancedLazyResultSetto support generic connection types, aligning with the asynchronous functionality enhancements.Also applies to: 17-20, 39-39
src/graph/utils.rs (2)
9-48: The implementation ofgenerate_create_index_queryis robust and handles optional parameters effectively.
50-78: The implementation ofgenerate_drop_index_queryis clear and correctly formats the query string based on the index and entity type.src/response/mod.rs (2)
7-7: The structFalkorResponseis well-documented and effectively uses generics to handle different types of data.
53-55: The implementation ofFalkorParsableforFalkorResponse<Vec<T>>is robust, ensuring type safety and comprehensive error handling.src/response/constraint.rs (2)
6-6: The structConstraintis well-documented and effectively uses enums to define various types of constraints.
52-54: The implementation ofFalkorParsableforConstraintis robust, ensuring type safety and comprehensive error handling.examples/asynchronous.rs (1)
6-70: The exampleasynchronous.rseffectively demonstrates the usage of the asynchronous client, including graph operations and handling multiple tasks concurrently.src/response/index.rs (1)
93-95: The addition of generic typeCinfrom_falkor_valuemethod enhances flexibility by supporting both sync and async operations.src/value/graph_entities.rs (1)
33-35: The modifications to support generic connections in the parsing functions forNodeandEdgealign well with the asynchronous capabilities being introduced.Also applies to: 77-79
src/connection/blocking.rs (1)
74-81: The implementation ofcheck_is_redis_sentinelmethod is correct and effectively checks the Redis mode.src/connection/asynchronous.rs (1)
72-79: Validate the logic for checking if Redis is a sentinel.The method
check_is_redis_sentinelassumes "redis_mode" will be present and correctly identifies a sentinel. Verify this assumption against the Redis documentation or by testing against a real Redis instance.Verification successful
The presence of the "redis_mode" field in the Redis info output has been confirmed. The method
check_is_redis_sentinelcorrectly checks for this field to identify if Redis is running in sentinel mode.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the presence and correctness of "redis_mode" in Redis info. # Test: Fetch Redis info and check for "redis_mode". echo "INFO" | redis-cliLength of output: 100
Script:
#!/bin/bash # Description: Verify the presence and correctness of "redis_mode" in Redis info. # Test: Fetch Redis info and check for "redis_mode" using a different method. redis-server --version if [ $? -eq 0 ]; then redis-server --daemonize yes sleep 1 echo "INFO" | redis-cli | grep "redis_mode" redis-cli shutdown else echo "Redis server is not installed." fiLength of output: 195
Script:
#!/bin/bash # Description: Fetch Redis documentation to verify the presence of "redis_mode" in Redis info. # Fetch the Redis documentation for the INFO command. curl -s https://raw.githubusercontent.com/redis/redis/unstable/src/server.c | grep -A 10 "redis_mode"Length of output: 623
src/client/mod.rs (2)
10-11: The conditional compilation for thetokiofeature is correctly implemented to include asynchronous functionality only when the feature is enabled.Also applies to: 13-14
154-172: The asynchronous methodget_sentinel_client_asynccorrectly parallels its synchronous counterpart. Ensure that the error handling is consistent across both synchronous and asynchronous methods.Verification successful
The implementations of both
get_sentinel_clientandget_sentinel_client_asynchave been successfully extracted. Upon review, it is evident that both methods handle errors in a consistent manner by using similar error handling mechanisms and returning appropriate results.
get_sentinel_clientuses synchronous calls and handles errors using?operator.get_sentinel_client_asyncuses asynchronous calls and handles errors similarly withawaitand?operators.Both methods call
get_sentinel_client_commonand handle the potential errors fromcheck_is_redis_sentinelandexecute_commandin a consistent manner.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that error handling is consistent across synchronous and asynchronous methods. # Test: Search for error handling in synchronous and asynchronous methods. Expect: Consistent error messages and types. rg --type rust $'get_sentinel_client|get_sentinel_client_async'Length of output: 594
Script:
#!/bin/bash # Extract the full implementation of get_sentinel_client and get_sentinel_client_async from src/client/mod.rs ast-grep --lang rust --pattern $'fn get_sentinel_client($_, $_) { $$$ }' src/client/mod.rs ast-grep --lang rust --pattern $'async fn get_sentinel_client_async($_, $_) { $$$ }' src/client/mod.rsLength of output: 199
Script:
#!/bin/bash # Adjusted patterns to extract the full implementation of get_sentinel_client and get_sentinel_client_async from src/client/mod.rs ast-grep --lang rust --pattern $'pub(crate) fn get_sentinel_client($_, $_) { $$$ }' src/client/mod.rs ast-grep --lang rust --pattern $'pub(crate) async fn get_sentinel_client_async($_, $_) { $$$ }' src/client/mod.rsLength of output: 221
Script:
#!/bin/bash # Use rg to search for the function definitions and extract the surrounding lines rg 'pub\(crate\) fn get_sentinel_client' -A 20 src/client/mod.rs rg 'pub\(crate\) async fn get_sentinel_client_async' -A 20 src/client/mod.rsLength of output: 2523
src/value/utils.rs (2)
21-24: The generic implementation ofparse_typeto accommodate any type implementingProvidesSyncConnectionsis a good design choice, promoting flexibility and reusability.
6-8: The imports are well-organized, and the inclusion of necessary traits and types for the operations in this file is appropriate.src/client/blocking.rs (2)
45-47: The implementation ofget_connectionin theProvidesSyncConnectionstrait forFalkorSyncClientInneris concise and leverages the inner mutex effectively.
225-225: The test utility functioncreate_empty_inner_sync_clientis a good addition for facilitating isolated tests without needing a real connection setup.src/graph_schema/mod.rs (2)
71-92: The implementation ofGraphSchemawith generic connection handling and manual clone is well-done. Consider adding a comment explaining the choice ofArcfor future maintainability.
94-97: Initialization ofGraphSchemawith generics is correctly implemented.src/client/asynchronous.rs (4)
34-48: Theborrow_connectionmethod is correctly implemented with appropriate asynchronous handling and error management.
74-104: Thecreatemethod for setting up theFalkorAsyncClientwith a connection pool is correctly implemented, with robust error handling and asynchronous operations.
135-171: Theconfig_getandconfig_setmethods inFalkorAsyncClientare well-implemented, providing clear and efficient handling of configuration settings asynchronously.Also applies to: 173-193
217-232: Thecopy_graphmethod is correctly implemented, effectively using asynchronous operations to manage graph copying.src/graph/query_builder.rs (2)
Line range hint
39-97: The enhancements toQueryBuilderto support both synchronous and asynchronous operations using generics are well-implemented, providing flexibility and robustness in handling different types of queries.Also applies to: 120-141
Line range hint
291-410: TheProcedureQueryBuilderis well-implemented, effectively supporting both read-only and standard procedure calls with appropriate handling of arguments and yields. The flexibility in handling both synchronous and asynchronous operations is commendable.src/graph/blocking.rs (1)
350-354: Validate the implementation ofHasGraphSchema.The implementation of
HasGraphSchemaforSyncGraphlooks correct and properly exposes the mutable reference tograph_schema. This is crucial for operations that might modify the schema during graph operations.
| @@ -88,7 +91,7 @@ impl SyncGraph { | |||
| pub fn profile<'a>( | |||
| &'a mut self, | |||
| query_string: &'a str, | |||
| ) -> QueryBuilder<ExecutionPlan, &str> { | |||
| ) -> QueryBuilder<ExecutionPlan, &str, FalkorSyncClientInner, Self> { | |||
There was a problem hiding this comment.
Review the use of generics in QueryBuilder and ProcedureQueryBuilder.
The introduction of generics in QueryBuilder and ProcedureQueryBuilder to accommodate both synchronous and asynchronous clients is a significant change. It's important to ensure that these changes are well-documented and that examples are provided in the documentation to help users understand how to use these modified structures effectively.
Also applies to: 109-109, 124-129, 145-150, 166-166, 182-182, 191-192, 213-224, 231-238, 247-251
| async fn execute_command( | ||
| &self, | ||
| command: &str, | ||
| subcommand: Option<&str>, | ||
| params: Option<&[&str]>, | ||
| ) -> FalkorResult<FalkorValue> { | ||
| self.client | ||
| .borrow_connection(self.client.clone()) | ||
| .await? | ||
| .execute_command(Some(self.graph_name.as_str()), command, subcommand, params) | ||
| .await | ||
| } |
There was a problem hiding this comment.
Optimize connection borrowing pattern.
The method execute_command borrows a connection and immediately uses it. This pattern can be optimized by directly passing the necessary parameters to a lower-level function that handles connection borrowing internally, reducing the complexity and potential for errors in connection management.
|
|
||
| ```toml | ||
| falkordb = { version = "0.1.0" } | ||
| falkordb = { version = "*" } |
There was a problem hiding this comment.
Update the version specification to be more specific.
Using a wildcard for the version specification (version = "*") can lead to unpredictable behavior as any version of the dependency might be used, potentially breaking the build or introducing subtle bugs. It's better to specify a more precise version range.
- falkordb = { version = "*" }
+ falkordb = { version = "^0.1" } # Adjust according to the latest stable release| pub(crate) enum FalkorAsyncConnection { | ||
| #[allow(unused)] | ||
| None, | ||
| #[cfg(feature = "redis")] | ||
| Redis(redis::aio::MultiplexedConnection), | ||
| } |
There was a problem hiding this comment.
Ensure proper feature gating for Redis-specific code.
The Redis connection is wrapped in a #[cfg(feature = "redis")] attribute, which is good for conditional compilation. However, ensure that the entire project consistently handles the absence of this feature to avoid compilation errors.
EmilyMatt
changed the title
Summary by CodeRabbit
New Features
tokio, allowing users to interact with FalkorDB asynchronously.rustlsornative-tls.Documentation
falkordb.Chores
deny.tomlto include"windows-sys".Examples