cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Modeling annotations
Date Sun, 08 Jan 2017 08:36:06 GMT
[splitting annotations discussion in its own thread]

> On Jan 8, 2017, at 10:40 AM, Andrus Adamchik <> wrote:
>> On Jan 8, 2017, at 1:12 AM, Michael Gentry <> wrote:
>> 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.

More on why annotations being on the IDE side is important ... Annotations do not have to
be trivial. They may have a bunch of references to other code. So taking them out of reach
of the IDE refactoring is really inconvenient. E.g.:

@MyA {
  handler =,
  types = {"a", "b", "c"},
  name = "foo"
class MyClass {}

So here if you say rename "MyHandler", you have a good chance of missing it in the XML. We've
seen this problem repeatedly with Listener classes mapped in the Modeler, which led us to
remove Listener functionality from the Modeler completely. This generally made me extremely
wary of keeping non-ORM pieces of code in the XML. 

So perhaps there's another solution for annotations? Such as replacing the "generation gap"
pattern in the future versions with smarter "merging" code generators (e.g. using @javax.annotation.Generated
to tell the code generated by us from the code created by the user).


View raw message