Cayenne Modeler Extensions

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Cayenne Modeler Extensions

Andrus Adamchik

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
Reply | Threaded
Open this post in threaded view
|

Re: Cayenne Modeler Extensions

Michael Gentry
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 <[hidden email]>
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
Reply | Threaded
Open this post in threaded view
|

Re: Cayenne Modeler Extensions

Aristedes Maniatis-2
In reply to this post by Andrus Adamchik
On 8/1/17 1:17am, Andrus Adamchik wrote:
> * 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.

Don't forget other types of data like DB indicies, which could be used at run-time (by Liquibase/Flyway/etc) but isn't needed by Cayenne itself.

Ari



--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
Reply | Threaded
Open this post in threaded view
|

Re: Cayenne Modeler Extensions

Andrus Adamchik
In reply to this post by Michael Gentry

> On Jan 8, 2017, at 1:12 AM, Michael Gentry <[hidden email]> 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





Reply | Threaded
Open this post in threaded view
|

Re: Cayenne Modeler Extensions

Andrus Adamchik
In reply to this post by Aristedes Maniatis-2

> On Jan 8, 2017, at 5:31 AM, Aristedes Maniatis <[hidden email]> wrote:
>
> On 8/1/17 1:17am, Andrus Adamchik wrote:
>> * 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.
>
> Don't forget other types of data like DB indicies, which could be used at run-time (by Liquibase/Flyway/etc) but isn't needed by Cayenne itself.

True. If we figure out handling of extra project files, we will open the door to a number of nice extensions.

Andrus
Reply | Threaded
Open this post in threaded view
|

Re: Cayenne Modeler Extensions

Andrus Adamchik
In reply to this post by Andrus Adamchik

> On Jan 8, 2017, at 10:40 AM, Andrus Adamchik <[hidden email]> wrote:
>
>>
>> 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.

On the XML side, I guess we should start using all the standard XML machinery to enable extensions. Namely namespaces and entity includes. This should clean up the format, allowing to split the overall model into multiple files, and cleanly separate pieces handled by different Cayenne "plugins". E.g.:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE doc [
    <!ENTITY metadata SYSTEM "cgenmstuff.xml">
]>
<data-map xmlns="http://cayenne.apache.org/schema/9/modelMap"
          xmlns:cdbi="http://...."
          xmlns:cgenm="http://...."
          project-version="9">

    <!-- Including metadata file as an entity -->
    &metadata

    <!-- Including cdbimport filter inline -->
    <cdbi:filter>
    <cdbi:catalog>mydb</cdbi:catalog>
    </cdbi:filter>

    <db-entity name="TABLE1">
       <!-- Including comments inline -->
       <cgenm:comment>DB comment</cgenm:comment>
       <db-attribute name="ID" type="INTEGER" isPrimaryKey="true" isMandatory="true"/>
    </db-entity>
    ...
</data-map>

Andrus

Reply | Threaded
Open this post in threaded view
|

Modeling annotations

Andrus Adamchik
In reply to this post by Andrus Adamchik
[splitting annotations discussion in its own thread]

> On Jan 8, 2017, at 10:40 AM, Andrus Adamchik <[hidden email]> wrote:
>
>> On Jan 8, 2017, at 1:12 AM, Michael Gentry <[hidden email]> 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 = com.foo.MyHandler,
  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

Reply | Threaded
Open this post in threaded view
|

Re: Cayenne Modeler Extensions

Michael Gentry
In reply to this post by Andrus Adamchik
On Sun, Jan 8, 2017 at 2:40 AM, Andrus Adamchik <[hidden email]>
wrote:

>
> > On Jan 8, 2017, at 1:12 AM, Michael Gentry <[hidden email]> 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).
>

My initial thoughts were to just include DB comments (that are in CM) in
the SQL generation feature, but this can clearly be expanded upon.


> 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.
>

Still on 3.0.2 ...  :-)


> 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.
>

Since you spun off a separate thread, I'll comment over there...


> 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.
>

I was fully expecting this metadata to be available to more than CM.  It
would absolutely have to be available to cgen, for example.  I also want VM
template management to be incorporated into CM, too.  It might be overkill,
but you should be able to specify which template to use for which entity.
Most wouldn't do this, of course, but it should be doable.

mrg
Reply | Threaded
Open this post in threaded view
|

Re: Modeling annotations

Michael Gentry
In reply to this post by Andrus Adamchik
My initial desire for annotation support was to allow for JAXB annotations (
http://www.techferry.com/articles/jaxb-annotations.html), 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 = com.foo.MyHandler,
        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);
    }
[repeat]

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.

Thanks,

mrg


On Sun, Jan 8, 2017 at 3:36 AM, Andrus Adamchik <[hidden email]>
wrote:

> [splitting annotations discussion in its own thread]
>
> > On Jan 8, 2017, at 10:40 AM, Andrus Adamchik <[hidden email]>
> wrote:
> >
> >> On Jan 8, 2017, at 1:12 AM, Michael Gentry <[hidden email]> 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 = com.foo.MyHandler,
>   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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Modeling annotations

Andrus Adamchik
I wonder if "regular" things like JAXB annotations can be generated via a custom template?

Andrus

> On Jan 16, 2017, at 11:20 AM, Michael Gentry <[hidden email]> wrote:
>
> My initial desire for annotation support was to allow for JAXB annotations (
> http://www.techferry.com/articles/jaxb-annotations.html), 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 = com.foo.MyHandler,
>        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);
>    }
> [repeat]
>
> 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.
>
> Thanks,
>
> mrg
>
>
> On Sun, Jan 8, 2017 at 3:36 AM, Andrus Adamchik <[hidden email]>
> wrote:
>
>> [splitting annotations discussion in its own thread]
>>
>>> On Jan 8, 2017, at 10:40 AM, Andrus Adamchik <[hidden email]>
>> wrote:
>>>
>>>> On Jan 8, 2017, at 1:12 AM, Michael Gentry <[hidden email]> 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 = com.foo.MyHandler,
>>  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
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Modeling annotations

Michael Gentry-2
I don't think that will allow enough granularity or control.  For example,
there are certain fields we don't want exposed, etc.  A custom template
would apply the same annotation everywhere.  That's why in the new CM I was
adding annotation support on everything.


On Tue, Jan 17, 2017 at 9:58 AM, Andrus Adamchik <[hidden email]>
wrote:

> I wonder if "regular" things like JAXB annotations can be generated via a
> custom template?
>
> Andrus
>
> > On Jan 16, 2017, at 11:20 AM, Michael Gentry <[hidden email]>
> wrote:
> >
> > My initial desire for annotation support was to allow for JAXB
> annotations (
> > http://www.techferry.com/articles/jaxb-annotations.html), 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 = com.foo.MyHandler,
> >        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);
> >    }
> > [repeat]
> >
> > 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.
> >
> > Thanks,
> >
> > mrg
> >
> >
> > On Sun, Jan 8, 2017 at 3:36 AM, Andrus Adamchik <[hidden email]>
> > wrote:
> >
> >> [splitting annotations discussion in its own thread]
> >>
> >>> On Jan 8, 2017, at 10:40 AM, Andrus Adamchik <[hidden email]>
> >> wrote:
> >>>
> >>>> On Jan 8, 2017, at 1:12 AM, Michael Gentry <[hidden email]>
> 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 = com.foo.MyHandler,
> >>  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
> >>
> >>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Modeling annotations

Andrus Adamchik
Fair enough. While I would likely still avoid annotations in the model myself, I see where you are coming from.

It would be ideal if we could implement proper model extensions mechanism [1]. Then annotations, cdbimport specs, DB comments or any other arbitrary metadata can be done as independent optional modules.

Andrus

[1] https://lists.apache.org/thread.html/068029fd0197b1d55e2206bf666a84c5d24e20235fad3340901358de@%3Cdev.cayenne.apache.org%3E



> On Jan 17, 2017, at 10:07 AM, Michael Gentry <[hidden email]> wrote:
>
> I don't think that will allow enough granularity or control.  For example,
> there are certain fields we don't want exposed, etc.  A custom template
> would apply the same annotation everywhere.  That's why in the new CM I was
> adding annotation support on everything.
>
>
> On Tue, Jan 17, 2017 at 9:58 AM, Andrus Adamchik <[hidden email]>
> wrote:
>
>> I wonder if "regular" things like JAXB annotations can be generated via a
>> custom template?
>>
>> Andrus
>>
>>> On Jan 16, 2017, at 11:20 AM, Michael Gentry <[hidden email]>
>> wrote:
>>>
>>> My initial desire for annotation support was to allow for JAXB
>> annotations (
>>> http://www.techferry.com/articles/jaxb-annotations.html), 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 = com.foo.MyHandler,
>>>       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);
>>>   }
>>> [repeat]
>>>
>>> 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.
>>>
>>> Thanks,
>>>
>>> mrg
>>>
>>>
>>> On Sun, Jan 8, 2017 at 3:36 AM, Andrus Adamchik <[hidden email]>
>>> wrote:
>>>
>>>> [splitting annotations discussion in its own thread]
>>>>
>>>>> On Jan 8, 2017, at 10:40 AM, Andrus Adamchik <[hidden email]>
>>>> wrote:
>>>>>
>>>>>> On Jan 8, 2017, at 1:12 AM, Michael Gentry <[hidden email]>
>> 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 = com.foo.MyHandler,
>>>> 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
>>>>
>>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Modeling annotations

Michael Gentry-2
Well, I haven't made any XML changes yet.  My first goal is to be able to
edit the currently supported model before adding to it.  We'll have plenty
of time to noodle over XML changes/design for this effort.

Thanks,

mrg


On Tue, Jan 17, 2017 at 10:17 AM, Andrus Adamchik <[hidden email]>
wrote:

> Fair enough. While I would likely still avoid annotations in the model
> myself, I see where you are coming from.
>
> It would be ideal if we could implement proper model extensions mechanism
> [1]. Then annotations, cdbimport specs, DB comments or any other arbitrary
> metadata can be done as independent optional modules.
>
> Andrus
>
> [1] https://lists.apache.org/thread.html/068029fd0197b1d55e2206bf666a84
> c5d24e20235fad3340901358de@%3Cdev.cayenne.apache.org%3E
>
>
>
> > On Jan 17, 2017, at 10:07 AM, Michael Gentry <[hidden email]>
> wrote:
> >
> > I don't think that will allow enough granularity or control.  For
> example,
> > there are certain fields we don't want exposed, etc.  A custom template
> > would apply the same annotation everywhere.  That's why in the new CM I
> was
> > adding annotation support on everything.
> >
> >
> > On Tue, Jan 17, 2017 at 9:58 AM, Andrus Adamchik <[hidden email]
> >
> > wrote:
> >
> >> I wonder if "regular" things like JAXB annotations can be generated via
> a
> >> custom template?
> >>
> >> Andrus
> >>
> >>> On Jan 16, 2017, at 11:20 AM, Michael Gentry <[hidden email]>
> >> wrote:
> >>>
> >>> My initial desire for annotation support was to allow for JAXB
> >> annotations (
> >>> http://www.techferry.com/articles/jaxb-annotations.html), 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 = com.foo.MyHandler,
> >>>       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);
> >>>   }
> >>> [repeat]
> >>>
> >>> 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.
> >>>
> >>> Thanks,
> >>>
> >>> mrg
> >>>
> >>>
> >>> On Sun, Jan 8, 2017 at 3:36 AM, Andrus Adamchik <
> [hidden email]>
> >>> wrote:
> >>>
> >>>> [splitting annotations discussion in its own thread]
> >>>>
> >>>>> On Jan 8, 2017, at 10:40 AM, Andrus Adamchik <[hidden email]
> >
> >>>> wrote:
> >>>>>
> >>>>>> On Jan 8, 2017, at 1:12 AM, Michael Gentry <[hidden email]>
> >> 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 = com.foo.MyHandler,
> >>>> 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
> >>>>
> >>>>
> >>
> >>
>
>