> On Jan 8, 2017, at 1:12 AM, Michael Gentry <blackn...@gmail.com> wrote: > 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?
Or just always override from DB (after all you want a single source of metadata in your stack). > 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.) Yeah, DB-first flow wasn't feasible in 3.1. And until M3/M4 wasn't stable enough in 4.0 (M5 has the last few known bugs squashed). Try it now though. It works like a charm. > 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. But how does this save us work creating annotations? If you had to override 1000's of methods, then you will have to create 1000's of annotations in the Modeler as well to achieve the same effect. The only way to cut down on the number of (repeating) annotations is if they are are all applied to the same properties of different entities. Then they can be moved to a separate interface (or a superclass common to all entities), all outside the Modeler and within the IDE. > 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. This definitely has merit. Lazy loading of all this metadata (i.e. skipping it in runtime) is a good idea. But we need to make sure this file is fully integrated in Cayenne project model and toolchain and can be loaded on-demand from anywhere, not just the Modeler. Also we need to look at the bigger picture here. We want to be able to add and manage extra project files for many different reasons. I have this list for now: 1. cgen-related metadata - this discussion. 2. cgen custom templates - makes sense to keep them in the project and in version control together with Cayenne XML files. 3. cdbimport filters and settings - currently this is configured inside the build system (pom.xml, etc.), but I'd really like to move it to the Cayenne project (and make it editable in the Modeler). So a generic mechanism for referencing and managing extra files with the project (lazy-loading, saving, etc.) is a prerequisite to implementing the above. Andrus
