add model based nominal type system

[fubhy]

No description provided.

[nikgraf]

Note: this will be moved to be implicit and doesn't have to be defined.

[cmwhited]

I definitely like the use of Model. The approach feels really clean.
It does create a bit of a change that in order to define a "schema", we end up defining multiple models, vs the single schema object we did have. Which feels more like a database approach to solving it, vs a document approach.
All-in-all, I think I prefer this approach.

@fubhy curious on the use of Model from @effect/sql vs the Data or Schema class from effect??

[fubhy]

I definitely like the use of Model. The approach feels really clean. It does create a bit of a change that in order to define a "schema", we end up defining multiple models, vs the single schema object we did have. Which feels more like a database approach to solving it, vs a document approach. All-in-all, I think I prefer this approach.

@fubhy curious on the use of Model from @effect/sql vs the Data or Schema class from effect??

We'd be using @effect/experimental/VariantSchema going forward and creating our own Domain Model Abstraction layer around that instead of borrowing the one from @effect/sql. I just didn't want to do that just yet (time constrained).

[fubhy]

We need encoding & decoding capabiltiies (encode to write to store in a serialized, json-safe format and, when selecting from the store (useQuery) decode it to "upcast" the value to a runtime representation that matches the domain model definition of the application domain (e.g. upcasting a date string to a date object).

Therefore, we must use Schema. Data is just a plain data definition, no encoding&decoding capabilities. And Schema itself is not enough because we need multiple representations of the same schema (one for insertion, one for update, one for reading). E.g. when "reading", the select variant is used (hence VariantSchema) that'll have a guaranteed id property. Whereas when writing, the id property is not needed because it is implicit and generated by the underlying storage engine (e.g. before dropping the payload into the sync engine in our case).

[yanivtal]

Looks amazing! Just added a few questions.

[yanivtal]

With this model, can an entity still have many types? Is this making it so we only create an entity of type person? Or could we define it so that when you create the entity it has types: Person, Artist, Historical figure?

[fubhy]

For such a case, we'd probably require the explicit creation of a polymorphic entity, e.g. something along these lines:

useCreateEntity(Model.Polymorphic(Person, Artist, Historical))

That said, this is actually impossible to represent with "mathematical accuracy / determinism" as soon as there's overlapping field declarations with different schema constraints. As such, with a polymorphic type you are essentially throwing away constrained domain modeling. I'm also not sure if I'm seeing the use-case. But I've not been in those discussions.