To add relations to our types and code, we need to do a few things.
- add relations to the schemas and example
- update type template to add fields and helpers
- update our custom code in the resource handlers
Recall that the core
hof/schema/dm.#Datamodel has a
#Relation with two strings,
To show you how we can calculate extra fields from existing ones,
we will modify our example
which already extends
Here, we add a
GoType field for template rendering
We of course need to add the relations between our types
to the datamodel we are using for our server.
Note how we do not have to add
It will still be available in our template input though.
We specify that a User has many Todos and that a Todo belongs to a User.
We now need to implement type relations in our templates. We show the whole file here as much was added. Note
- We stored the top-level TYPE in
$Tso we can reference it in nested template scopes.
- some edge cases in the
*With*helpers are omitted and left to the user.
UserReadHandlerto use the new library function
TodoCreateHandlerto have a username query parameter and assign the user. Note, we would normally determine the User with auth and context.
We also need to add a query parameter to an automatically generated route from a resource from our datamodel.
For now, we added it manually to the handler, as in the code just above. We leave addition of this query parameter as a thought experiment.
- Can you conditionally add it in the
#DatamodelToResourcehelper? (hint, this is probably the complex, but better way, check for
Reln == "BelongsTo")
- Can you unconditionally add it through the example design? (hint, you will need to unify with the generator
Regen, Rebuild, Rerun
We can now
hof gen ./examples/server.cue.
If you see any merge conflicts, you will need to fix those first.
Try rebuilding, rerunning, and making calls to the server to create users and todos.
Some comments on the difficulties of data modeling, templating, and the spectrum of languages and technologies.
- type and relation generation is going to language and technology specific
- hof aims to maintain an abstract representation
- users can extend to add the specifics needed
- we expect that middle layers will capture common groups like SQL, OOP, and visibility (public/private)
- best practice is to use labels which are not likely to conflict, can always namespace and nest
[Link to a more in depth discussion] of the issue with creating a schema for data models and the complexities with multiple
We’ll also see better ways to construct the library later,
when we introduce