You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-`ModelCreateUpdateBase`: Base class containing shared functionality for proto conversion and field mapping
62
+
-`ModelCreate`: Inherits from `ModelCreateUpdateBase` with generic typing for creation operations
63
+
-`ModelUpdate`: Inherits from `ModelCreateUpdateBase` with additional field mask support for updates
64
+
65
+
2.**Domain-Specific Base Classes**:
66
+
Create a base class that inherits from `ModelCreateUpdateBase` and contains:
67
+
- All shared field definitions
68
+
- Shared `_to_proto_helpers` configuration for complex proto mappings
69
+
- Common validation logic using `@model_validator`
70
+
It may not always make sense to implement a base class if there is little/no overlap in fields or protos.
71
+
72
+
3.**Create and Update Models**:
73
+
-`{Domain}Create`: Inherits from both `{Domain}Base` and `ModelCreate[{CreateProto}]`
74
+
- Include create only fields and validators
75
+
-`{Domain}Update`: Inherits from both `{Domain}Base` and `ModelUpdate[{UpdateProto}]`
76
+
- Include update only fields and validators
77
+
78
+
#### Proto Mapping Helpers
79
+
80
+
Use `MappingHelper` for complex proto field mappings when the Pydantic model doesn't match the proto model exactly:
81
+
-`proto_attr_path`: Dot-separated path to the proto field
82
+
-`update_field`: Field name for update masks (optional)
83
+
-`converter`: Function/class to convert the value (optional)
84
+
85
+
#### Validation Guidelines
86
+
87
+
- Use `@model_validator(mode="after")` for cross-field validation
88
+
- Prefix validation method names with `_` (e.g., `_validate_time_fields`) since these don't need to be user visible
89
+
- Keep validation logic in the base class when shared between create/update
90
+
- Add specific validation in create/update classes as needed
55
91
56
92
### High-Level APIs
57
93
@@ -62,6 +98,62 @@ Static and class methods should be avoided since these cannot have associated sy
62
98
63
99
All high-level APIs should inherit from `ResourceBase` from `sift_client/resources/_base.py`.
64
100
101
+
#### Resource Method Patterns
102
+
103
+
Resource classes should implement consistent patterns for common operations. Use the helper methods from `ResourceBase` to build standard filter arguments.
104
+
105
+
**Important:** Arguments that represent another Sift Type should always accept both the object instance and its ID string. This provides flexibility for users who may have either form.
106
+
107
+
108
+
**Note**: If the proto API does not support filters for a resource, the API should be updated to make the resource filterable in a consistent way with other resources.
0 commit comments