ComposeDB allows us to define our data models in an interoperable way, but we don’t have this interoperability option for scalars. There are only primitives. It would be great to be able to share these as well. For example, I could define and save a scalar named email, and all developers could use it commonly. These are structures that are repeatedly determined and often lead to incompatibilities. Especially when building in web3, the number of these types is much higher.
Wouldn’t it be great if ComposeDB had a structure where we could define and share such types too?
I think the core problem that @seref is pointing to in the post is a real one, and something like the solution proposed is probably a good idea. I think the devil is in the details though, it’s not clear to me exactly what form a registry like this should take, what sort of tooling we should build into the product to use and enable it, or how we can actually promote convergence and consensus around these scalar types throughout our community. But it’s definitely worth thinking about and exploring more.
My first reaction would be that in the end we are always converting the scalar to a data type supported by the database we work with to index the data so in @seref example, the email would end up being a string.
On our side we also create models directly using the JS libraries and are following the JSON schema rules instead of using ComposeDB libraries so from my experience I view the email as a specific entity with some rules defining the formatting like this:
But in the end the type is still a string and for composability it would probably be better to push developers to use the same model (maybe UserEmail which would respect the format shared above) instead of pushing developers to use the same custom scalar but with a different model.