In this approach you generate the foreign keys from the YAML definitions.
Everything is defined in YAML first.
However I would like to eventually write a tool to reverse engineer an existing
schema into YAML.
Nevertheless you too could parse the SQL model instead of coming up with a YAML
equivalent for foreign key constraints. ;-)
Ormin is interesting, but I prefer the Nexus method of using generated procs
and types. I think it's a good thing to have many different ORM libraries for
people to choose from.
In Ormin I parse the SQL model at compile-time. And I don't generate Nim types
for the model at all, instead Ormin focusses on providing the tools to generate
prepared statements that are type-checked against the model. This way you don't
have to materialize a complete Nim object of all fields o
Here's simpler way to write the models in Nim:
import schema_types
proc setupModels*() =
var model: Model
model.name = "Account User"
model.description = "Users by account"
model.tableOptions.namingCase = snakeCase
var
I was thinking that I do prefer the YAML method. Although it's not too
difficult to support both approaches. I can't say I like the macro method.
It sacrifices a lot of clarity, compared to the yaml version.
A `model` macro is the way to go, imho, and would e.g. let you use Nim syntax
for that whole fields section. At the very least you could get rid of the extra
boiler plate.
model:
## this is to manage users
ty
Are `snakeCase` , `stringType` , the various constraints etc. all enums?
I think choosing to make this data available at runtime (by having it like this
instead of as a type) may open you up to a lot of interesting possibilities.
Could the declaration also be a `const` ?
Here's the schema_types.nim file, sorry I should have included this in my
original post. The consts could be enums.
import options
const
snakeCase* = "snakeCase"
stringType* = "string"
ulidGenerator* = "ulid"
autoGenerateConstraint*
One of the feedback items for Nexus was the ability to define models with Nim
code, particularly Nim objects. Defining with Nim object types isn't ideal,
because there's no validation or any way to provide defaults, so for the
prototype code below I went with procs that help you define objects.
10 matches
Mail list logo
