Re: cgen into the future

On 11/10/21 2:56am, Michael Gentry wrote:
> If someone generated the "incorrect" classes
> from the default templates, cgen would fix that mistake for them when they
> built the project (happened frequently enough that I made it part of the
> build process).

This isn't true when deleting or renaming an entity in the model. It is 
really important to me that this kind of mistake causes a compilation 
error. Multiply this problem out by antlr, swagger and cayenne entities 
and I'm very happy with our design choice to keep generated code out of VCS.

This isn't hypothetical. Years ago we had a real problem that took days 
to solve; additional entities in our classpath caused a subtle problem 
in places you'd not expect. Almost lost a customer over it, so I've 
little interest in going back there.


> if you
> have to checkout a previous version and build it with a newer (or perhaps
> even older) version of Cayenne to see the superclasses, you may not be
> seeing the same superclasses as originally intended.

I'm pretty happy with our use of gradle to lock dependencies to a 
reproducible version. We even use gradle to lock in the version of node 
which compiles our typescript. And our DSL documentation is generated 
live [1], parsing the code without having to remember to commit the 
generated docs.


Anyhow, each to their own. Some people might like to commit js files 
compiled from typescript so they can search on what is running in 
production without compiling. For us, the opposite approach has worked well.


Cheers

Ari


[1] 
https://github.com/ishgroup/oncourse/blob/main/buildSrc/apidoc/src/main/groovy/au/com/ish/docs/DslGroovyRootDocBuilder.groovy