Hi Andrus, I expect the XML format I'm proposing to change, so discussion is quite welcome.
I'd forgotten I had included DB comments, but I can see the value of them. I suppose if you are doing a sync with the DB, if there are differences, query the user for which one to keep/use? Our use-cases never involve DB syncs, so this could be quite a blind spot for me. (We maintain Flyway migration scripts separately and update the Cayenne model by hand as needed.) We had looked at overriding getters/setters for annotations, but we didn't want to do that 1000s of times, so we gave up. I see value in the superclass being able to have annotations along with JavaDocs for various attributes and relationships, plus the class itself. The superclass is essentially maintained outside of the IDE currently, anyway (you may look at the code, but you don't edit it), so I don't think it'll be too bad. I'm also viewing this as a separate XML file. One that wouldn't need to be deployed, although it wouldn't hurt if present. Nothing in it is required for runtime support, unlike the main model. Everything is class-generation extensions only. Thanks, mrg On Sat, Jan 7, 2017 at 9:17 AM, Andrus Adamchik <and...@objectstyle.org> wrote: > > Re: https://github.com/apache/cayenne-modeler/blob/master/ > docs/XML-Extensions.md > > Something to discuss in more detail. I understand the value of all this > extra metadata, I am just concerned about its maintenance and integration > in Cayenne. > > * Some of it we won't be able to ignore outside the Modeler. Specifically > DB comments need to be reverse-engineered with Maven/Ant/Gradle. So it has > to be a part of the core model. > > * Also concerned about managing annotations in the Modeler. Placing them > in XML makes it clunky. Annotations are not a part of "ORM" paradigm (as > they have nothing to do with DB), but now the users will have to maintain > them outside of the IDE. My current approach is to override a given getter > or setter in subclass and place annotations there. Not ideal, but highly > practical. > > Andrus
