cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gentry <>
Subject Re: Cayenne Modeler Extensions
Date Sat, 07 Jan 2017 22:12:57 GMT
Hi Andrus,

I expect the XML format I'm proposing to change, so discussion is quite

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

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.



On Sat, Jan 7, 2017 at 9:17 AM, Andrus Adamchik <>

> Re:
> docs/
> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message