cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gentry <>
Subject Re: Modeling annotations
Date Mon, 16 Jan 2017 16:20:57 GMT
My initial desire for annotation support was to allow for JAXB annotations (, but of course it
could be used for other purposes.  I'm not sure how much IDE refactoring
would take place in this arena.  I concede renaming "MyHandler" could be
problematic, or at least surprising -- hopefully you'd notice the _
superclasses had unexpected changes.

I really want to be able to specify annotations, but I'd also hate to lose
the generation gap pattern and "uglify" the subclasses (if they even
existed at that point) with something like this:

    @MyA {
        handler =,
        types = {"a", "b", "c"},
        name = "foo"
    @Generated // By Cayenne - DO NOT EDIT
    @XmlElement // I intentionally put this annotation after @Generated to
maybe cause problems...
    public String getNotes() {
        return (String)readProperty(NOTES_PROPERTY);

You'd also need to "protect" NOTES_PROPERTY as well, all the relationship
methods, etc.

I can see it being quite difficult to merge without causing problems, too.
You'd also need to properly parse the method to find the end -- people can
have custom templates where more logic is added into the generated methods,
so you can't just skip to the next }.  Also, how do you track renames?  If
someone changed "notes" in CM to "note" and regenerated classes, would it
create a new getter/setter for "note", delete "notes" and all annotations
on it, losing the annotations you had intended for "notes" (which is now
"note")?  This would also be quite surprising for most users.



On Sun, Jan 8, 2017 at 3:36 AM, Andrus Adamchik <>

> [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).
> Andrus

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