Defaults should "just work"

[Gurpartap]

Default config needs some tinkering:

• Set StaticDir = ""
• Enable typemaps by default*
• Drop schema out of path directives (public)
• Put all generated files in the same folder

Maybe also:

• Provide a demo.sql migration file

But certainly:

• Add CRUD templates that "just work"

*Also add the following types:

• "bigint" = "int64"
• "int8" = "int64"
• "double precision" = "float64"
• "jsonb" = "[]byte"
• "citext" = "string"
• ???

[natefinch]

the static directory is a problem. but the rest is really supposed to be up to the user to determine.

however maybe we need a gnorm demo command that spits out a valid example to show how the pieces run together.

[Gurpartap]

Every implementation will eventually have its own configuration. However, it would be decent for someone trying gnorm out to be able to start playing with the generated DSL asap, figure out if this project fits their needs, and then go back and reconfigure/customize templates.

[daniel-reed]

I agree with the assertion that defaults should just work. Adding a command to copy (and not overwrite) a sane table, schema, and enum template would go a long way in getting a new user up and running quickly. Yes, they will need to modify it at some point, but that is a lot easier than writing one from scratch.

I was also a little confused as to why the typemaps were not enabled by default. It should work great for most users and the remaining users would only need to modify what is already there.

[natefinch]

Well, ok, so part of the reason is that, in theory, Gnorm is not just for Go programmers. This could be used for creating docs, for creating protobuf definitions, or even code in some other language.

Also, the typemaps are DB-specific, like MySQL has longtext and postgres doesn't. As more databases are added, they're more likely to get different types.

What we might want is like gnorm init <language> <database> and have pre-made templates for each. so like you'd do gnorm init go mysql or gnorm init protobuf postgres

The idea is to eventually have a gallery of solutions the way Hugo has a gallery of themes. It's a little harder here, because we can't just steal port themes from pre-existing generators (or, maybe we can, if anyone knows of some).

[daniel-reed]

The expanded init command would be a good middle ground. This would be easy to direct new users to do through a quick start or getting started section.

In the short term (prior to getting the gallery going), we could also consider a separate github project with either templates organized into directories or an index md that points to other github projects that contain just a set of quality templates. Essentially a curated collection.

[natefinch]

The curated collection definitely is a good idea. I have a set of templates that create Go DB wrappers mostly ready to go, converted from what we use at work.

I'd also like to see if there's a way to make it easy to convert from xo to gnorm. Xo is like a specialized version of gnorm that only produces go code.

Xo has a lot of custom functions that we could probably duplicate with a plugin.... but I haven't looked at how hard it would be to convert. My guess is right now it would be quite a bit of work, even if the general layout of the code is the same... xo has a lot of very customized functions for turning its schema into go code. With embedded templates (#60) and plugins, we might be able to make it a lot easier, though.

[h4ckm03d]

Any update for this issue?

[natefinch]

https://github.com/gnormal/postgres-go is a ready-to-use set of templates for generating go code for a postgres DB that are 99% the same as what I use at work.