feat: Dart SDK update for version 19.2.0 #94
Conversation
WalkthroughAdds transaction support across Databases and TablesDB: new endpoints (list/create/get/update/delete transactions, createOperations) and optional transactionId propagated to document/row operations. Introduces models Transaction and TransactionList and exports them. Updates docs with examples for transactional usage, including create/update/delete/get/list transactions and operations. Bumps package to 19.2.0 and updates SDK headers/user-agent versions. README and CHANGELOG updated. Adds unit and service tests for transaction APIs and models. Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (3)
test/src/models/transaction_list_test.dart (1)
15-16: Inconsistent indentation.Lines 15-16 have extra leading whitespace compared to line 17, breaking visual alignment of the expect statements within the test block.
Apply this diff to align the indentation:
- expect(result.total, 5); - expect(result.transactions, []); + expect(result.total, 5); + expect(result.transactions, []);test/src/models/transaction_test.dart (1)
19-24: Inconsistent indentation.Lines 19-24 have extra leading whitespace with varying indentation levels, breaking visual alignment of the expect statements within the test block.
Apply this diff to align the indentation:
- expect(result.$id, '259125845563242502'); - expect(result.$createdAt, '2020-10-15T06:38:00.000+00:00'); - expect(result.$updatedAt, '2020-10-15T06:38:00.000+00:00'); - expect(result.status, 'pending'); - expect(result.operations, 5); - expect(result.expiresAt, '2020-10-15T06:38:00.000+00:00'); + expect(result.$id, '259125845563242502'); + expect(result.$createdAt, '2020-10-15T06:38:00.000+00:00'); + expect(result.$updatedAt, '2020-10-15T06:38:00.000+00:00'); + expect(result.status, 'pending'); + expect(result.operations, 5); + expect(result.expiresAt, '2020-10-15T06:38:00.000+00:00');lib/services/tables_db.dart (1)
168-188: Improve type safety for theoperationsparameter.Line 171 uses the untyped generic
List<Map>?, which provides no compile-time guarantees about the map's key and value types.Apply this diff to use a fully typed parameter:
Future<models.Transaction> createOperations({ required String transactionId, - List<Map>? operations, + List<Map<String, dynamic>>? operations, }) async {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (52)
CHANGELOG.md(1 hunks)README.md(1 hunks)docs/examples/databases/create-document.md(1 hunks)docs/examples/databases/create-documents.md(1 hunks)docs/examples/databases/create-operations.md(1 hunks)docs/examples/databases/create-transaction.md(1 hunks)docs/examples/databases/decrement-document-attribute.md(1 hunks)docs/examples/databases/delete-document.md(1 hunks)docs/examples/databases/delete-documents.md(1 hunks)docs/examples/databases/delete-transaction.md(1 hunks)docs/examples/databases/get-document.md(1 hunks)docs/examples/databases/get-transaction.md(1 hunks)docs/examples/databases/increment-document-attribute.md(1 hunks)docs/examples/databases/list-documents.md(1 hunks)docs/examples/databases/list-transactions.md(1 hunks)docs/examples/databases/update-document.md(1 hunks)docs/examples/databases/update-documents.md(1 hunks)docs/examples/databases/update-transaction.md(1 hunks)docs/examples/databases/upsert-document.md(1 hunks)docs/examples/databases/upsert-documents.md(1 hunks)docs/examples/messaging/create-push.md(1 hunks)docs/examples/messaging/update-push.md(1 hunks)docs/examples/tablesdb/create-operations.md(1 hunks)docs/examples/tablesdb/create-row.md(1 hunks)docs/examples/tablesdb/create-rows.md(1 hunks)docs/examples/tablesdb/create-transaction.md(1 hunks)docs/examples/tablesdb/decrement-row-column.md(1 hunks)docs/examples/tablesdb/delete-row.md(1 hunks)docs/examples/tablesdb/delete-rows.md(1 hunks)docs/examples/tablesdb/delete-transaction.md(1 hunks)docs/examples/tablesdb/get-row.md(1 hunks)docs/examples/tablesdb/get-transaction.md(1 hunks)docs/examples/tablesdb/increment-row-column.md(1 hunks)docs/examples/tablesdb/list-rows.md(1 hunks)docs/examples/tablesdb/list-transactions.md(1 hunks)docs/examples/tablesdb/update-row.md(1 hunks)docs/examples/tablesdb/update-rows.md(1 hunks)docs/examples/tablesdb/update-transaction.md(1 hunks)docs/examples/tablesdb/upsert-row.md(1 hunks)docs/examples/tablesdb/upsert-rows.md(1 hunks)lib/models.dart(2 hunks)lib/services/databases.dart(19 hunks)lib/services/tables_db.dart(18 hunks)lib/src/client_browser.dart(1 hunks)lib/src/client_io.dart(1 hunks)lib/src/models/transaction.dart(1 hunks)lib/src/models/transaction_list.dart(1 hunks)pubspec.yaml(1 hunks)test/services/databases_test.dart(1 hunks)test/services/tables_db_test.dart(1 hunks)test/src/models/transaction_list_test.dart(1 hunks)test/src/models/transaction_test.dart(1 hunks)
🧰 Additional context used
🪛 markdownlint-cli2 (0.18.1)
docs/examples/databases/create-operations.md
13-13: Hard tabs
Column: 1
(MD010, no-hard-tabs)
14-14: Hard tabs
Column: 1
(MD010, no-hard-tabs)
15-15: Hard tabs
Column: 1
(MD010, no-hard-tabs)
16-16: Hard tabs
Column: 1
(MD010, no-hard-tabs)
17-17: Hard tabs
Column: 1
(MD010, no-hard-tabs)
18-18: Hard tabs
Column: 1
(MD010, no-hard-tabs)
19-19: Hard tabs
Column: 1
(MD010, no-hard-tabs)
20-20: Hard tabs
Column: 1
(MD010, no-hard-tabs)
21-21: Hard tabs
Column: 1
(MD010, no-hard-tabs)
22-22: Hard tabs
Column: 1
(MD010, no-hard-tabs)
docs/examples/tablesdb/create-operations.md
13-13: Hard tabs
Column: 1
(MD010, no-hard-tabs)
14-14: Hard tabs
Column: 1
(MD010, no-hard-tabs)
15-15: Hard tabs
Column: 1
(MD010, no-hard-tabs)
16-16: Hard tabs
Column: 1
(MD010, no-hard-tabs)
17-17: Hard tabs
Column: 1
(MD010, no-hard-tabs)
18-18: Hard tabs
Column: 1
(MD010, no-hard-tabs)
19-19: Hard tabs
Column: 1
(MD010, no-hard-tabs)
20-20: Hard tabs
Column: 1
(MD010, no-hard-tabs)
21-21: Hard tabs
Column: 1
(MD010, no-hard-tabs)
22-22: Hard tabs
Column: 1
(MD010, no-hard-tabs)
🔇 Additional comments (26)
pubspec.yaml (1)
2-2: LGTM! Version bump is consistent with the release.The version update to 19.2.0 aligns with the transaction support feature addition documented in the CHANGELOG.
docs/examples/databases/get-transaction.md (1)
1-12: LGTM! Documentation example is clear and correct.The example properly demonstrates the transaction retrieval API with appropriate client setup and parameter usage.
CHANGELOG.md (1)
3-5: LGTM! Release notes are concise and accurate.The changelog entry clearly describes the transaction support feature added in version 19.2.0.
lib/src/client_browser.dart (1)
33-33: LGTM! SDK version header correctly updated.The x-sdk-version header now reflects the 19.2.0 release, consistent with the version bump in pubspec.yaml.
lib/models.dart (1)
41-41: LGTM! New model exports follow established patterns.The part declarations for
transaction_list.dartandtransaction.dartare correctly placed and follow the existing export structure for other models.Also applies to: 126-126
docs/examples/databases/update-transaction.md (1)
1-14: LGTM! Documentation example demonstrates optional parameters clearly.The example properly shows the updateTransaction API with optional
commitandrollbackparameters, making it clear to users that these are optional flags.lib/src/client_io.dart (1)
39-41: LGTM! SDK version identifiers correctly updated.Both the x-sdk-version header and user-agent string now reflect version 19.2.0, ensuring proper SDK identification in server environments.
README.md (1)
26-26: LGTM! Installation instructions updated for new release.The dependency version correctly references
^19.2.0, allowing users to install the latest version with compatible updates.docs/examples/databases/upsert-document.md (1)
16-16: LGTM!The documentation correctly reflects the new optional
transactionIdparameter for transactional support inupsertDocument.docs/examples/databases/get-document.md (1)
15-15: LGTM!The documentation correctly reflects the new optional
transactionIdparameter for transactional support ingetDocument.docs/examples/tablesdb/delete-row.md (1)
14-14: LGTM!The documentation correctly reflects the new optional
transactionIdparameter for transactional support indeleteRow.docs/examples/tablesdb/delete-transaction.md (1)
1-12: LGTM!The example correctly demonstrates the usage of the new
deleteTransactionendpoint with proper client configuration and parameter passing.docs/examples/tablesdb/increment-row-column.md (1)
17-17: LGTM!The documentation correctly reflects the new optional
transactionIdparameter for transactional support inincrementRowColumn.docs/examples/databases/create-documents.md (1)
10-15: LGTM! Clear documentation of the new transactionId parameter.The example clearly demonstrates the optional transactionId parameter usage for transactional document creation.
docs/examples/tablesdb/create-transaction.md (1)
1-12: LGTM! Clear example of transaction creation.The example demonstrates the basic usage of creating a transaction with an optional TTL parameter. The code is straightforward and follows standard documentation patterns.
test/services/tables_db_test.dart (1)
93-208: LGTM! Comprehensive test coverage for transaction endpoints.The new test cases systematically cover all six transaction-related endpoints:
- listTransactions (GET)
- createTransaction (POST)
- getTransaction (GET)
- updateTransaction (PATCH)
- deleteTransaction (DELETE)
- createOperations (POST)
Each test follows the established pattern: mock data, mock HTTP call, invoke method, and assert the return type. The test coverage ensures the new transaction functionality is properly validated.
docs/examples/tablesdb/list-transactions.md (1)
1-12: LGTM! Clear example of listing transactions.The example demonstrates how to list transactions with optional queries. The code is straightforward and follows standard documentation patterns.
lib/src/models/transaction_list.dart (1)
13-20: Verify null safety for transactions field.The
fromMapfactory accessesmap['transactions']without null checking (Line 17). If the API can return null for the transactions field, this will throw a runtime exception.Ensure that the API always returns a non-null transactions array, or add null safety:
factory TransactionList.fromMap(Map<String, dynamic> map) { return TransactionList( total: map['total'], transactions: map['transactions'] != null ? List<Transaction>.from( map['transactions'].map((p) => Transaction.fromMap(p)), ) : [], ); }test/services/databases_test.dart (1)
93-208: LGTM! Comprehensive test coverage for Databases transaction endpoints.The new test cases provide complete coverage for all transaction-related endpoints, mirroring the TablesDB tests for consistency:
- listTransactions (GET → TransactionList)
- createTransaction (POST → Transaction)
- getTransaction (GET → Transaction)
- updateTransaction (PATCH → Transaction)
- deleteTransaction (DELETE)
- createOperations (POST → Transaction)
Each test follows the established mocking and assertion pattern, ensuring proper validation of the new functionality.
lib/services/databases.dart (2)
66-196: LGTM! Well-structured transaction endpoint implementations.The six new transaction endpoints are properly implemented:
- listTransactions: GET endpoint with query support
- createTransaction: POST endpoint with optional TTL
- getTransaction: GET endpoint by transaction ID
- updateTransaction: PATCH endpoint supporting commit/rollback
- deleteTransaction: DELETE endpoint by transaction ID
- createOperations: POST endpoint for bulk operations
All endpoints follow consistent patterns: proper HTTP methods, path construction, header setup, and return type mapping to Transaction or TransactionList models.
1520-1942: LGTM! Consistent transactionId propagation across document operations.The optional
transactionIdparameter has been systematically added to all document-related operations:
- listDocuments, createDocument, createDocuments
- upsertDocuments, updateDocuments, deleteDocuments
- getDocument, upsertDocument, updateDocument, deleteDocument
- decrementDocumentAttribute, incrementDocumentAttribute
The implementation is consistent across all methods: the parameter is optional (String?), properly added to apiParams, and maintains backward compatibility. This enables all document operations to participate in transactional contexts.
lib/services/tables_db.dart (5)
58-76: LGTM!The
listTransactionsmethod correctly implements a GET endpoint returningTransactionListwith optional query filtering.
78-94: LGTM!The
createTransactionmethod correctly implements a POST endpoint with optional TTL parameter and returns aTransactionobject.
96-117: LGTM!The
getTransactionmethod correctly retrieves a transaction by ID using path parameter substitution.
147-166: LGTM!The
deleteTransactionmethod correctly implements a DELETE endpoint. Thecontent-typeheader is consistent with other DELETE operations in this service.
1506-1531: LGTM!The transaction context propagation is correctly implemented across all row operations. The optional
transactionIdparameter is consistently added to API params, properly handling both GET requests (query params) and POST/PUT/PATCH/DELETE requests (request body).Also applies to: 1537-1566, 1572-1597, 1604-1629, 1633-1660, 1664-1689, 1693-1721, 1727-1757, 1761-1791, 1794-1818, 1821-1853, 1856-1888
| { | ||
| "action": "create", | ||
| "databaseId": "<DATABASE_ID>", | ||
| "collectionId": "<COLLECTION_ID>", | ||
| "documentId": "<DOCUMENT_ID>", | ||
| "data": { | ||
| "name": "Walter O'Brien" | ||
| } | ||
| } | ||
| ], // (optional) |
There was a problem hiding this comment.
Replace hard tabs with spaces.
Markdownlint flagged hard tabs on these lines, which should be replaced with spaces for consistent indentation.
Apply this diff to replace hard tabs with spaces:
operations: [
- {
- "action": "create",
- "databaseId": "<DATABASE_ID>",
- "collectionId": "<COLLECTION_ID>",
- "documentId": "<DOCUMENT_ID>",
- "data": {
- "name": "Walter O'Brien"
- }
- }
+ {
+ "action": "create",
+ "databaseId": "<DATABASE_ID>",
+ "collectionId": "<COLLECTION_ID>",
+ "documentId": "<DOCUMENT_ID>",
+ "data": {
+ "name": "Walter O'Brien"
+ }
+ }
], // (optional)Committable suggestion skipped: line range outside the PR's diff.
🧰 Tools
🪛 markdownlint-cli2 (0.18.1)
13-13: Hard tabs
Column: 1
(MD010, no-hard-tabs)
14-14: Hard tabs
Column: 1
(MD010, no-hard-tabs)
15-15: Hard tabs
Column: 1
(MD010, no-hard-tabs)
16-16: Hard tabs
Column: 1
(MD010, no-hard-tabs)
17-17: Hard tabs
Column: 1
(MD010, no-hard-tabs)
18-18: Hard tabs
Column: 1
(MD010, no-hard-tabs)
19-19: Hard tabs
Column: 1
(MD010, no-hard-tabs)
20-20: Hard tabs
Column: 1
(MD010, no-hard-tabs)
21-21: Hard tabs
Column: 1
(MD010, no-hard-tabs)
22-22: Hard tabs
Column: 1
(MD010, no-hard-tabs)
🤖 Prompt for AI Agents
In docs/examples/databases/create-operations.md around lines 13 to 22, replace
hard tab characters used for indentation with spaces to satisfy markdownlint;
update each indented line (the JSON block items and the closing bracket/comment
line) by converting tabs to spaces (use the repository's standard — typically 2
or 4 spaces — to match surrounding file), ensuring consistent indentation
throughout the code block and re-run markdownlint to verify the warning is
resolved.
| Transaction result = await tablesDB.createOperations( | ||
| transactionId: '<TRANSACTION_ID>', | ||
| operations: [ | ||
| { | ||
| "action": "create", | ||
| "databaseId": "<DATABASE_ID>", | ||
| "tableId": "<TABLE_ID>", | ||
| "rowId": "<ROW_ID>", | ||
| "data": { | ||
| "name": "Walter O'Brien" | ||
| } | ||
| } | ||
| ], // (optional) | ||
| ); |
There was a problem hiding this comment.
Replace hard tabs with spaces.
The example uses hard tabs for indentation in the operations array (lines 13-22). Replace them with spaces to comply with Markdown standards.
Apply this diff to fix the indentation:
Transaction result = await tablesDB.createOperations(
transactionId: '<TRANSACTION_ID>',
operations: [
- {
- "action": "create",
- "databaseId": "<DATABASE_ID>",
- "tableId": "<TABLE_ID>",
- "rowId": "<ROW_ID>",
- "data": {
- "name": "Walter O'Brien"
- }
- }
+ {
+ "action": "create",
+ "databaseId": "<DATABASE_ID>",
+ "tableId": "<TABLE_ID>",
+ "rowId": "<ROW_ID>",
+ "data": {
+ "name": "Walter O'Brien"
+ }
+ }
], // (optional)
);Committable suggestion skipped: line range outside the PR's diff.
🧰 Tools
🪛 markdownlint-cli2 (0.18.1)
13-13: Hard tabs
Column: 1
(MD010, no-hard-tabs)
14-14: Hard tabs
Column: 1
(MD010, no-hard-tabs)
15-15: Hard tabs
Column: 1
(MD010, no-hard-tabs)
16-16: Hard tabs
Column: 1
(MD010, no-hard-tabs)
17-17: Hard tabs
Column: 1
(MD010, no-hard-tabs)
18-18: Hard tabs
Column: 1
(MD010, no-hard-tabs)
19-19: Hard tabs
Column: 1
(MD010, no-hard-tabs)
20-20: Hard tabs
Column: 1
(MD010, no-hard-tabs)
21-21: Hard tabs
Column: 1
(MD010, no-hard-tabs)
22-22: Hard tabs
Column: 1
(MD010, no-hard-tabs)
🤖 Prompt for AI Agents
In docs/examples/tablesdb/create-operations.md around lines 10 to 23, the
example snippet uses hard tab characters for indentation inside the operations
array; replace all hard tabs on lines 13–22 with standard spaces (use two or
four spaces per indent consistent with the rest of the file) so the Markdown
renders correctly and complies with repository formatting.
| /// Update a transaction, to either commit or roll back its operations. | ||
| Future<models.Transaction> updateTransaction({ | ||
| required String transactionId, | ||
| bool? commit, | ||
| bool? rollback, | ||
| }) async { | ||
| final String apiPath = '/tablesdb/transactions/{transactionId}'.replaceAll( | ||
| '{transactionId}', | ||
| transactionId, | ||
| ); | ||
|
|
||
| final Map<String, dynamic> apiParams = { | ||
| 'commit': commit, | ||
| 'rollback': rollback, | ||
| }; | ||
|
|
||
| final Map<String, String> apiHeaders = {'content-type': 'application/json'}; | ||
|
|
||
| final res = await client.call( | ||
| HttpMethod.patch, | ||
| path: apiPath, | ||
| params: apiParams, | ||
| headers: apiHeaders, | ||
| ); | ||
|
|
||
| return models.Transaction.fromMap(res.data); | ||
| } |
There was a problem hiding this comment.
Validate mutually exclusive commit and rollback parameters.
The updateTransaction method accepts both commit and rollback as optional booleans, which allows ambiguous states:
- Both
true(contradictory) - Both
falseornull(no-op?)
These parameters should be mutually exclusive. While this may be enforced server-side, client-side validation would catch errors earlier and improve the developer experience.
Consider adding validation before the API call:
Future<models.Transaction> updateTransaction({
required String transactionId,
bool? commit,
bool? rollback,
}) async {
if (commit == true && rollback == true) {
throw ArgumentError('Cannot specify both commit and rollback');
}
if (commit != true && rollback != true) {
throw ArgumentError('Must specify either commit or rollback');
}
final String apiPath = '/tablesdb/transactions/{transactionId}'.replaceAll(
'{transactionId}',
transactionId,
);
// ... rest of implementation
}🤖 Prompt for AI Agents
In lib/services/tables_db.dart around lines 119 to 145, the updateTransaction
method accepts optional commit and rollback booleans that can be both true, both
false/null, or omitted; add client-side validation before calling the API to
ensure they are mutually exclusive and exactly one is specified: throw an
ArgumentError if commit and rollback are both true, and throw an ArgumentError
if neither is true (commit != true && rollback != true), then proceed to build
apiPath, apiParams and make the client.call as before.
| factory Transaction.fromMap(Map<String, dynamic> map) { | ||
| return Transaction( | ||
| $id: map['\$id'].toString(), | ||
| $createdAt: map['\$createdAt'].toString(), | ||
| $updatedAt: map['\$updatedAt'].toString(), | ||
| status: map['status'].toString(), | ||
| operations: map['operations'], | ||
| expiresAt: map['expiresAt'].toString(), | ||
| ); | ||
| } |
There was a problem hiding this comment.
Add type safety for the operations field deserialization.
Line 38 assigns map['operations'] directly without type conversion or null-safety, unlike the string fields that use .toString(). If the API returns null or a non-int type (e.g., a string "5"), this will cause a runtime error.
Apply this diff to add safe type conversion:
factory Transaction.fromMap(Map<String, dynamic> map) {
return Transaction(
$id: map['\$id'].toString(),
$createdAt: map['\$createdAt'].toString(),
$updatedAt: map['\$updatedAt'].toString(),
status: map['status'].toString(),
- operations: map['operations'],
+ operations: (map['operations'] is int)
+ ? map['operations'] as int
+ : int.parse(map['operations'].toString()),
expiresAt: map['expiresAt'].toString(),
);
}📝 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.
| factory Transaction.fromMap(Map<String, dynamic> map) { | |
| return Transaction( | |
| $id: map['\$id'].toString(), | |
| $createdAt: map['\$createdAt'].toString(), | |
| $updatedAt: map['\$updatedAt'].toString(), | |
| status: map['status'].toString(), | |
| operations: map['operations'], | |
| expiresAt: map['expiresAt'].toString(), | |
| ); | |
| } | |
| factory Transaction.fromMap(Map<String, dynamic> map) { | |
| return Transaction( | |
| $id: map['\$id'].toString(), | |
| $createdAt: map['\$createdAt'].toString(), | |
| $updatedAt: map['\$updatedAt'].toString(), | |
| status: map['status'].toString(), | |
| operations: (map['operations'] is int) | |
| ? map['operations'] as int | |
| : int.parse(map['operations'].toString()), | |
| expiresAt: map['expiresAt'].toString(), | |
| ); | |
| } |
2 participants
This PR contains updates to the Dart SDK for version 19.2.0.
Summary by CodeRabbit
New Features
Documentation
Tests
Chores