templates: QOL suggestions

[switchupcb]

Here are a list of features that aren't necessarily issues, but make using the library more complex:

Quality of Life Issues

1. Templates are only organized by driver in certain cases.
   • templates are split into yaml, json, createdb, then gotpl.
   • gotpl pertains to SQL, sqlserver, oracle, postgres, etc
   • In contrast, xo is only run with one driver (schema) at a time.
   • suggestion: organize templates by driver; split templates into drivers.
2. Keeping templates up to date is tedious
   • Users are advised to migrate to updated templates (according to #309)
   • This commit provides custom functions.
   • In order to update the templates, we must replace our template files (i.e funcs.go.tpl, typedef, etc)
   • suggestion: add/document how we can add a funcs2.go.tpl that doesn't interfere with funcs.go
     • There was a way to do this (I think) but it's hard to find out with recent updates.
     • see 1: simplifies changes in other files (db.go.tpl, etc)
3. Using funcs.go.tpl is tedious
   • funcs.go.tpl is 1223 lines with comments as documentation.
     • This in part due to lots of duplicated code (specific to context implementation). The start to a solution was proposed but didn't align with the repository.
   • suggestion: document important functions of funcs.go.tpl; split into funcs directory and give it domains.
     • For example
     • How to use custom go types for postgresql types? #321
     • Expose SQL type information in gotpl types #315
     • templates: how to create WHERE string for multiple primary keys #317
     • How to get all primary keys (only), columns (all), etc.

Other Suggestions

Batch Templates

Default xo templates are focused around context code which generate single-object CRUD functions. The user is able to optimize this by using custom functions to change template implementation: a single network request can be sent via batch (with or without transactions). This implies multiple objects are being used in a function.

In contrast, there are no templates which provide use for multiple objects. For example, an SQL statement such as

INSERT INTO users (name) VALUES ($1);
INSERT INTO users (name) VALUES ($1);
INSERT INTO users (name) VALUES ($1);

can be turned into

INSERT INTO users (name)
VALUES
    ($1),
    ($2),
    ($3);

This would be an interesting template to have but there is no indication this would be supported. The README used to say it wasn't focused on optimization.

Domain Templates

Default xo templates are focused around generating models with respective single-object CRUD functions. As a result, these function similar to Data Access Objects (DAOs). This library would become a standard for database generation if it included a way to map these DAO models to external application-specific models. An example of this occurring would be in a repository pattern where multiple DAOs may be involved within a single domain object.

There is also no indication on whether this would be supported.

[kenshaw]

@switchupcb I appreciate your suggestions, please feel free to send actual code changes via a PR and I'll consider them, if they are inline with the goals of the project and are well written. If xo doesn't work for your use case, there are a number of other tools that are out there that may work better for you. xo is a very opinionated tool that has been made open-source in case it ends up useful to other people. I am in process of making the templates more dynamic, but at the end of the day, the templates are very much tied to the internal architecture and logic of the xo tool itself, which is not likely to be changed/overhauled in a significant way anytime soon. While I'd like to support all previous versions of xo templates, that's neither realistic nor feasible.

[switchupcb]

if they are inline with the goals of the project

Which suggestions are inline with the goals of the project? I will PR a roadmap for template organization this next week.

While I'd like to support all previous versions of xo templates, that's neither realistic nor feasible.

I'm pretty sure this is possible right now with the addition of custom funcs. You would have to encourage people to use an additional funcs.go.tpl (which I will call funcs2.go.tpl for simplicity sake) that adds functions to the FuncMap. In this way, any update to funcs.go.tpl will not actually override any custom functions.

The lack of documentation on funcs.go doesn't make it impossible to use, but it's a bit confusing. In order to add a function, we add it to the FuncMap and declare it in the same file. From there, we must figure out what v interface{} is which isn't clear on its use-case.

Does it represent the incoming schema (table, sproc, query, etc)?

[switchupcb]

Why close?