2 ms·

Thank you for taking the time (and referring to the point I made instead of criticizing the code, which is experimental and a little crappy in places). Looks i

Thank you for taking the time (and referring to the point I made instead of criticizing the code, which is experimental and a little crappy in places). Looks interesting and I will keep an eye on it. But am I right guessing that the TypeScript you linked would not work if the schema is only read at runtime?

spion 10y ago
Yeah, unfortunately. For something like that, code generation of at least the initial record types would be required for different schemas at before-compile-time. Then they can be transformed further by the type level language. Another option is to model the type as a dictionary of items, each item being a union of the possible types. There is a tradeoff here, and I believe that if the rest of the code statically assumes a concrete schema is in place, code generation + record types is the better choice. Otherwise, dictionaries would probably work okay. There are languages such as Idris and F# that have type providers which can be programmed to read and generate the types from the database, but AFAIK that would still happen at compile-time. https://docs.microsoft.com/en-us/dotnet/articles/fsharp/tutorials/type-providers/accessing-a-sql-database https://docs.microsoft.com/en-us/dotnet/articles/fsharp/tuto... - i guess its a kind of "built in" code generation.