Replace StorageClass with type specific interfaces #58

New issue

Closed

opened 2026-09-15 15:15:13 +02:00 by c.fahner · 1 comment

c.fahner commented

2026-09-15 15:15:13 +02:00

Owner

Currently, a Type serializes its value to one of the StorageClass types. The StorageClass of a field is determined using reflection over the return type of the serialize() method. This has a number of disadvantages:

A type cannot indicate multiple storage formats, which means databases with dedicated types cannot select the optimal type
~~It requires intermediate objects to indicate variants of PHP primitives, such as the Blob type representing binary data when a string would suffice~~
- The intermediate is still required since the insert/update operations still need to be able to distinguish them
A backwards compatibility break any time a new type is added to the StorageClass enum

Instead each Type should implement typed serialization interfaces, allowing implementations to more gradually opt-in to all known ORM types. For example, a type that can be stored as a string will implement StringSerializable which has a method serializeToString(mixed):SerializeException|string|null.

Issue #4 needs to be updated accordingly.

Currently, a `Type` serializes its value to one of the `StorageClass` types. The `StorageClass` of a field is determined using reflection over the return type of the `serialize()` method. This has a number of disadvantages: * A type cannot indicate multiple storage formats, which means databases with dedicated types cannot select the optimal type * ~~It requires intermediate objects to indicate variants of PHP primitives, such as the `Blob` type representing binary data when a `string` would suffice~~ * The intermediate is still required since the insert/update operations still need to be able to distinguish them * A backwards compatibility break any time a new type is added to the `StorageClass` enum Instead each `Type` should implement typed serialization interfaces, allowing implementations to more gradually opt-in to all known ORM types. For example, a type that can be stored as a `string` will implement `StringSerializable` which has a method `serializeToString(mixed):SerializeException|string|null`. Issue #4 needs to be updated accordingly.

c.fahner added this to the v0.2 milestone

2026-09-15 15:15:13 +02:00

c.fahner added the

Kind/Enhancement

Compat/Breaking

labels

2026-09-15 15:15:13 +02:00

c.fahner commented

2026-09-16 16:44:50 +02:00

Author

Owner

It is probably easier to leave the allowed insertable/settable types open ended (ie. mixed), and use the testing package to enforce a minimum set of types that need to be supported. See slendium/ocd-conformance-tests#6.

Instead, the TypeInfo utility should just report a single type string (and throw if the serialization return type hint is mixed, null, or a DNF type). This type string can then be used for further analysis. Implementations can throw if they don't recognize the given type.

The downside of having multiple serialization types and allowing the implementation to select an optimal type is that each implementation would also now have to provide some sort of value serializer that implements the specific rules for converting an input value into a schema-safe database value. It is probably easier to leave the allowed insertable/settable types open ended (ie. `mixed`), and use the testing package to enforce a minimum set of types that need to be supported. See slendium/ocd-conformance-tests#6. Instead, the `TypeInfo` utility should just report a single type string (and throw if the serialization return type hint is `mixed`, `null`, or a DNF type). This type string can then be used for further analysis. Implementations can throw if they don't recognize the given type.

c.fahner closed this issue

2026-09-16 16:44:50 +02:00

c.fahner removed this from the v0.2 milestone

2026-09-16 16:45:03 +02:00

c.fahner added

and removed

labels

2026-09-16 16:45:25 +02:00