search

gnormal / gnorm

A database-first code generator for any language
https://gnorm.org
Other
484 stars 39 forks source link

Defaults should "just work" #56

Open Gurpartap opened 7 years ago

Gurpartap commented 7 years ago

Default config needs some tinkering:

Maybe also:

But certainly:

*Also add the following types:

natefinch commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 (https://github.com/gnormal/gnorm/issues/60) and plugins, we might be able to make it a lot easier, though.

h4ckm03d commented 6 years ago

Any update for this issue?

natefinch commented 6 years ago

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.