Defaults should "just work" about gnorm HOT 8 OPEN

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.

from gnorm.

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.

from gnorm.

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.

from gnorm.

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).

from gnorm.

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.

from gnorm.

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.

from gnorm.

Any update for this issue?

from gnorm.

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.

from gnorm.