Is there an option to automatically include created/updated datetime fields on generated types?

[xo]

Is there an option to automatically include created/updated datetime fields on generated types?

[kenshaw]

I'm always open to pull requests, assuming that the code fits well into the existing codebase.

For the sake of simplicity, I'm assuming it was a typo and you meant 'datetime' fields.

There was another issue opened for this, basically concerning any database managed fields (for instance, a 'modification' timestamp or some such that gets automatically set (ie, via an update trigger, etc).

I'm not opposed to code for that, the problem is that there is no single general purpose way -- at least, not that I can think of -- that solves every use case/problem. ORMs usually tackle this by some sort of 'magic' -- meaning that they inspect the fields and then special logic is applied for those tables/fields. For instance, perhaps a mod_date field is ignored on Save/Update. The problem with this approach is that it forces specific naming conventions that 1) may not have been followed previously, and it is too difficult to update the existing schema to use it 2) may not be consistently named or have special rules for the underlying schema 3) in the future, the person adding tables/fields may prefer a different naming convention, 4) additionally, because xo supports multiple databases there are problems between the databases that would make this inconsistent between, for instance, MySQL, Oracle, et al.

In short, there is no pretty/elegant solution -- again, not that I can think of.

The way that I would suggest solving this is to copy the base templates, modify the logic to match your specific schema / use case, and then pass to xo the user supplied template path (--template-path):

cd /path/to/project

# copy templates
cp $GOPATH/src/github.com/knq/xo/templates/postgres.*.tpl /path/to/project/templates

# edit templates ...
vi templates/*.tpl

# pass to xo
mkdir models
xo pgsql://user:pass@host/dbname -o models --template-path ./templates

For instance, you could then introduce almost any logic you wanted in the templates that match your database schema:

{{if $cond}}/* some go code */{{end}}

If you have a suggestion / idea for a general way that this could be introduced into the xo codebase, without forcing users to adopt a specific schema design style, I'm very much open to hear it. If you can convince me it's a good idea, I'll even implement it!

In a couple of projects where we have decided to use xo, this in fact this is what we have done (ie, made our own base templates) -- because we didn't think what we were writing in the templates was a general purpose solution for the world at large (specifically, we have database managed fields such as modification times, etc).

[mccolljr]

I appreciate your response. I considered using my own set of templates, but what I was really looking for was a flag that could be set to make sure datetime fields matching my naming conventions to be set appropriately. I forked the repo and spent the last couple of hours shimming this in for mysql. I'm not going to submit a pull request at this time as the solution is not general, but for my purposes it basically looks at your Fields for a Type, and if it finds a datetime field named Created or Modified, it'll set Created on insert, and Modified each time the record is updated. This functionality is activated with the flag --autodates. I'll need to revisit it when I'm a little fresher.

[mccolljr]

I spent some time generalizing my solution this morning, and I think I see a way to include it without being too opinionated and as an entirely opt-in feature.

Right now, there are 3 new flags available

  --autodates            enables automatic population of DateTime fields named created and modified (mysql only)
  --modified MODIFIED    field name to treat as the modification time (autodates) [default: modified]
  --created CREATED      field name to treat as the creation time (autodates) [default: created]

...then, in internal/templates.go, in ExecuteTemplate, I modified the if statement used determine the template prefix as follows:

if a.LoaderType == "oci8" || a.LoaderType == "ora" {
        // force oracle for oci8 since the oracle driver doesn't recognize
        // 'oracle' as valid protocol
        loaderType = "oracle."
    } else {
        // For now, AutoDates only supports type templates in mysql
        // enable for other templates/schemes by changing this conditional
        if a.LoaderType == "mysql" && a.AutoDates && tt.String() == "type"{
            loaderType = "autodate." + LoaderType + "."
        } else {
            loaderType = a.LoaderType + "."
        }
    }

I added some helper functions in internal/funcs.go which are used in place of 'fieldnames' in my "autodates"-prefixed templates. This also allows someone who has their own template library to include templates supporting the autodate feature by supplying "autodate"-prefixed templates.

This i not a 100% solution, but it addresses a decent amount of use cases, I think.

TODO:

• define a function that will check the schema for compatibility with autodate, and use this in place of explicit conditional, as well as to warn the user and deactivate the autodate flag on unsupported schemas
• add support for more database/type combinations