Illustrates the inheritance hierarchy of various field types from a BaseField, detailing common and specific configurations and methods for data modeling.
classDiagram
class BaseField~T, TConfig~ {
+config: TConfig
+~: FieldInternals~T~
#cloneWith(override): BaseField
+nullable(): BaseField
+array(): BaseField
+id(): BaseField
+unique(): BaseField
+default(value): BaseField
}
class StringField~T~ {
+config: StringFieldConfig
+uuid(): StringField
+ulid(): StringField
+cuid(): StringField
+validator(v): StringField
}
class NumberField~T~ {
+config: NumberFieldConfig
+int(): NumberField
+float(): NumberField
+autoIncrement(): NumberField
}
class Relation~G, T~ {
+config: RelationConfig
+~: RelationInternals
+getter: () => Model
}
BaseField <|-- StringField
BaseField <|-- NumberField
BaseField <|-- BooleanField
BaseField <|-- BigIntField
BaseField <|-- DateTimeField
BaseField <|-- JsonField
BaseField <|-- BlobField
BaseField <|-- EnumField
BaseField <|-- VectorField
This class diagram shows the inheritance structure for a data modeling library's field types. It defines a BaseField with common configurations and internal properties, from which specialized fields like StringField, NumberField, Relation, BooleanField, BigIntField, DateTimeField, JsonField, BlobField, EnumField, and VectorField inherit. Each specialized field extends the base with type-specific configurations and methods.
Use this diagram to understand the core architecture of a data modeling or validation library, visualize the relationships between generic and specific field types, or design extensible data structures. It's useful for library developers, API designers, and anyone working with schema definitions.
To adapt this diagram, extend the BaseField with new custom field types, add specific validation methods to existing fields, or modify the 'config' and internal properties to support different runtime behaviors. New relations or constraints can be added to the Relation class or other fields.