feat: Apple SDK update for version 13.4.0 #95
Conversation
WalkthroughThis pull request releases version 13.4.0 with two primary features. First, a Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (1 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: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (19)
CHANGELOG.md(1 hunks)README.md(1 hunks)Sources/Appwrite/Client.swift(1 hunks)Sources/Appwrite/Operator.swift(1 hunks)Sources/Appwrite/Query.swift(1 hunks)Sources/Appwrite/Services/Account.swift(2 hunks)Sources/Appwrite/Services/Databases.swift(5 hunks)Sources/Appwrite/Services/Functions.swift(1 hunks)Sources/Appwrite/Services/Storage.swift(1 hunks)Sources/Appwrite/Services/TablesDb.swift(4 hunks)Sources/Appwrite/Services/Teams.swift(3 hunks)docs/examples/account/list-identities.md(1 hunks)docs/examples/account/list-logs.md(1 hunks)docs/examples/databases/list-documents.md(1 hunks)docs/examples/functions/list-executions.md(1 hunks)docs/examples/storage/list-files.md(1 hunks)docs/examples/tablesdb/list-rows.md(1 hunks)docs/examples/teams/list-memberships.md(1 hunks)docs/examples/teams/list.md(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
Sources/Appwrite/Operator.swift (1)
Sources/Appwrite/Query.swift (12)
equal(152-158)notEqual(160-166)greaterThan(184-190)greaterThanEqual(192-198)lessThan(168-174)lessThanEqual(176-182)contains(317-323)isNull(200-205)isNotNull(207-212)encode(34-50)encode(131-142)search(261-267)
🪛 SwiftLint (0.57.0)
Sources/Appwrite/Operator.swift
[Warning] 4-4: String enum values can be omitted when they are equal to the enumcase name
(redundant_string_enum_value)
[Warning] 5-5: String enum values can be omitted when they are equal to the enumcase name
(redundant_string_enum_value)
[Warning] 6-6: String enum values can be omitted when they are equal to the enumcase name
(redundant_string_enum_value)
[Warning] 7-7: String enum values can be omitted when they are equal to the enumcase name
(redundant_string_enum_value)
[Warning] 8-8: String enum values can be omitted when they are equal to the enumcase name
(redundant_string_enum_value)
[Warning] 9-9: String enum values can be omitted when they are equal to the enumcase name
(redundant_string_enum_value)
[Warning] 10-10: String enum values can be omitted when they are equal to the enumcase name
(redundant_string_enum_value)
[Warning] 11-11: String enum values can be omitted when they are equal to the enumcase name
(redundant_string_enum_value)
[Warning] 12-12: String enum values can be omitted when they are equal to the enumcase name
(redundant_string_enum_value)
🔇 Additional comments (15)
README.md (1)
34-34: LGTM! Version bump is correct.The package version update to 13.4.0 aligns with the PR objectives and is consistent with the version changes in other files.
docs/examples/account/list-identities.md (1)
10-11: LGTM! Documentation correctly demonstrates the new parameter.The example properly shows the usage of the new
totalparameter alongside the existingqueriesparameter.Sources/Appwrite/Client.swift (1)
26-26: LGTM! SDK version header correctly updated.The x-sdk-version header update to 13.4.0 is consistent with the version bump across the SDK.
CHANGELOG.md (1)
3-6: LGTM! Changelog entry is clear and informative.The changelog accurately documents the new features in version 13.4.0, including the performance-oriented
totalparameter and the newOperatorclass.docs/examples/account/list-logs.md (1)
10-11: LGTM! Documentation example is consistent and correct.The example properly demonstrates the new
totalparameter usage in thelistLogsmethod.Sources/Appwrite/Services/Functions.swift (2)
18-18: LGTM! Documentation updated for new parameter.The documentation comment correctly includes the new
totalparameter.
22-33: LGTM! Implementation of total parameter is correct.The
totalparameter is properly implemented as an optionalBool?with a nil default, maintaining backward compatibility. The parameter is correctly included in the API request parameters dictionary.docs/examples/functions/list-executions.md (1)
11-12: LGTM! Documentation example correctly shows the new parameter.The example properly demonstrates using the
totalparameter in thelistExecutionsmethod.Sources/Appwrite/Services/Storage.swift (2)
19-19: LGTM! Documentation updated for the new parameter.The documentation comment correctly includes the new
totalparameter.
23-36: LGTM! Implementation of total parameter is correct.The
totalparameter is properly implemented as an optionalBool?with a nil default value, maintaining backward compatibility. The parameter is correctly included in the API request parameters dictionary alongside existing parameters.docs/examples/teams/list-memberships.md (1)
9-14: Consistent documentation update for the newtotalparameter.The example correctly demonstrates the new optional
totalparameter being added to the TeamslistMembershipsmethod. The formatting with trailing comma and inline comment is consistent with the pattern across other documentation examples.docs/examples/tablesdb/list-rows.md (1)
9-15: Consistent documentation update for the newtotalparameter.The example correctly demonstrates the new optional
totalparameter being added to the TablesDBlistRowsmethod. Formatting and parameter organization are consistent with other examples in the PR.docs/examples/storage/list-files.md (1)
9-14: Consistent documentation update for the newtotalparameter.The example correctly demonstrates the new optional
totalparameter being added to the StoragelistFilesmethod. The formatting and parameter organization align with other examples in the PR.docs/examples/databases/list-documents.md (1)
9-15: Consistent documentation update for the newtotalparameter.The example correctly demonstrates the new optional
totalparameter being added to the DatabaseslistDocumentsmethod. Parameter organization and formatting are consistent with the broader documentation updates across the PR.docs/examples/teams/list.md (1)
9-13: Consistent documentation update for the newtotalparameter.The example correctly demonstrates the new optional
totalparameter being added to the Teamslistmethod. Formatting and structure are consistent with other examples in the PR.Summary
All five documentation example files follow a consistent and correct pattern for introducing the new optional
totalparameter to list methods. The examples:✅ Clearly demonstrate the new optional parameter with inline comments
✅ Maintain consistent formatting with trailing commas
✅ Usetotal: falseas the example value (indicating skipping row counts for performance optimization)
✅ Preserve all other parameters and functionalityNote: The PR mentions updates to 6 service classes (Account, Databases, Functions, Storage, TablesDb, Teams). The provided files show documentation for 4 of these services. The two missing examples (Account and Functions) were not included in this review batch, but based on the consistent pattern across all reviewed files, they should follow the same implementation if included.
| public static func increment(_ value: Double = 1, max: Double? = nil) -> String { | ||
| if value.isNaN || value.isInfinite { | ||
| fatalError("Value cannot be NaN or Infinity") | ||
| } | ||
| if let max = max, max.isNaN || max.isInfinite { | ||
| fatalError("Max cannot be NaN or Infinity") | ||
| } | ||
| var values: [Any] = [value] | ||
| if let max = max { | ||
| values.append(max) | ||
| } | ||
| return Operator(method: "increment", values: values).description | ||
| } | ||
|
|
||
| public static func decrement(_ value: Double = 1, min: Double? = nil) -> String { | ||
| if value.isNaN || value.isInfinite { | ||
| fatalError("Value cannot be NaN or Infinity") | ||
| } | ||
| if let min = min, min.isNaN || min.isInfinite { | ||
| fatalError("Min cannot be NaN or Infinity") | ||
| } | ||
| var values: [Any] = [value] | ||
| if let min = min { | ||
| values.append(min) | ||
| } | ||
| return Operator(method: "decrement", values: values).description | ||
| } | ||
|
|
||
| public static func multiply(_ factor: Double, max: Double? = nil) -> String { | ||
| if factor.isNaN || factor.isInfinite { | ||
| fatalError("Factor cannot be NaN or Infinity") | ||
| } | ||
| if let max = max, max.isNaN || max.isInfinite { | ||
| fatalError("Max cannot be NaN or Infinity") | ||
| } | ||
| var values: [Any] = [factor] | ||
| if let max = max { | ||
| values.append(max) | ||
| } | ||
| return Operator(method: "multiply", values: values).description | ||
| } | ||
|
|
||
| public static func divide(_ divisor: Double, min: Double? = nil) -> String { | ||
| if divisor.isNaN || divisor.isInfinite { | ||
| fatalError("Divisor cannot be NaN or Infinity") | ||
| } | ||
| if let min = min, min.isNaN || min.isInfinite { | ||
| fatalError("Min cannot be NaN or Infinity") | ||
| } | ||
| if divisor == 0 { | ||
| fatalError("Divisor cannot be zero") | ||
| } | ||
| var values: [Any] = [divisor] | ||
| if let min = min { | ||
| values.append(min) | ||
| } | ||
| return Operator(method: "divide", values: values).description | ||
| } | ||
|
|
||
| public static func modulo(_ divisor: Double) -> String { | ||
| if divisor.isNaN || divisor.isInfinite { | ||
| fatalError("Divisor cannot be NaN or Infinity") | ||
| } | ||
| if divisor == 0 { | ||
| fatalError("Divisor cannot be zero") | ||
| } | ||
| return Operator(method: "modulo", values: [divisor]).description | ||
| } |
There was a problem hiding this comment.
Don't crash consumer apps on invalid operator inputs
These helpers currently trap with fatalError whenever callers pass data like Double.nan, Double.infinity, or zero divisors. Because these APIs are public SDK surface, that means a runtime crash in any production app that forwards unvalidated user input—exactly what we’re trying to protect developers from. Apple’s own guidance and community best practices call out fatalError as a tool for unrecoverable programming mistakes, not regular input validation; in SDK code it becomes a foot‑gun for your customers.(compilenrun.com)
Instead of terminating the process, bubble up a normal error so callers can decide how to handle it (show a validation message, log and skip, etc.). One concrete way to achieve that without changing the JSON payload logic is to add a lightweight error enum and make these builders throws, for example:
+enum OperatorBuilderError: Error {
+ case invalidOperand(String)
+}
+
- public static func increment(_ value: Double = 1, max: Double? = nil) -> String {
- if value.isNaN || value.isInfinite {
- fatalError("Value cannot be NaN or Infinity")
- }
- if let max = max, max.isNaN || max.isInfinite {
- fatalError("Max cannot be NaN or Infinity")
- }
+ public static func increment(_ value: Double = 1, max: Double? = nil) throws -> String {
+ guard !value.isNaN && !value.isInfinite else {
+ throw OperatorBuilderError.invalidOperand("Value cannot be NaN or Infinity")
+ }
+ if let max = max {
+ guard !max.isNaN && !max.isInfinite else {
+ throw OperatorBuilderError.invalidOperand("Max cannot be NaN or Infinity")
+ }
+ }
var values: [Any] = [value]
if let max = max {
values.append(max)
}
return Operator(method: "increment", values: values).description
}Please apply the same pattern to decrement, multiply, divide, modulo, and power, so none of them can take the entire host app down.(compilenrun.com)
Committable suggestion skipped: line range outside the PR's diff.
This PR contains updates to the Apple SDK for version 13.4.0.
Summary by CodeRabbit
New Features
totalparameter to list operations for skipping row counting.Documentation