I saw that and knew that controller (e.g.bottle.go file) won't
be re-generated (by default). That's why I'm asking *how to deal with* the
situation when it *needs* to be re-generated again, *i.e.*, the round-robin
design approach. Anyway, I found the answer myself.
https://github.com/goadesign/exa
Here's the relevant paragraph from the guide you linked to (emphasis mine):
Note how goagen generated a main.go for our app as well as a skeleton
> controller (bottle.go). These two files are meant to help bootstrap a new
> development, *they won’t be re-generated (by default) if already present
Wow, quite impressive. I wish I had known it earlier.
One quick question, how does goa support round-robin design? I.e.,
from https://goa.design/learn/guide/ that I quickly peeked, it says
- use goa to generate a complete implementation, including bottle.go
- Then manually edit the bottle.go fi
take a look at goa and gorma: https://goa.design
goa generates an API from your description DSL, and Gorma generates the
data access layer. It uses gorm under the scenes so you'll have an easy
route to migration.
Brian
On Tuesday, December 20, 2016 at 8:46:12 AM UTC-5, Thomas Bellembois wrote:
