Home » Eclipse Projects » Dali » Any guidelines (now or planned) for extenders?
| Any guidelines (now or planned) for extenders? [message #434865] |
Tue, 15 April 2008 23:01  |
 Mike Yawn
Messages: 50
Registered: July 2009 |
Member |
|
|
I'm just wondering if the team has any plans to produce some sort of
document specifically targeted at extenders, rather than users, of Dali.
I mention this because I'm feeling somewhat lost in the inheritance
hierarchy at the moment. There's just a tremendous amount of code to
read and digest here to try to understand where to tie in; some sort of
high-level overview of the model, and rough sketch of the implementation
approach, might really help.
For example, because we added an attribute to the @Table annotation for
our own use, I need to be able to make corresponding extensions so that
our Dali platform can generate the additional attribute and parse it
back. Just trying to find all of the classes and interfaces that might
be related is daunting . .
TableAnnotation
TableImpl
NullTable
NullBaseTable
AbstractResourceTable
core.context.Table
db.Table
GenericJavaTable
AbstractJavaTable
JavaTable
TableComposite
and that's not including the helpers, superclasses and interfaces that
aren't specific to the Table implementation, but are obviously critical
to understanding the overall design -- like
JpaContextNode, JavaJpaContextNode, JpaNode, Model
AbstractJavaJpaContextNode, AbstractJpaContextNode, AbstractJpaNode
JavaResourceNode, AbstractJavaResourceNode
DeclarationAnnotationElementAdapter, AnnotationElementAdapter
PropertyAspectAdapter, PropertyValueModel, WritablePropertyValueModel
AspectAdapter
If there's anything that might serve as an introduction to all this (and
it's something you're willing to share), please let me know.
Otherwise I'll keep plugging away with the trial-and-error . . .
Mike
|
|
|
| Re: Any guidelines (now or planned) for extenders? [message #434867 is a reply to message #434865] |
Wed, 16 April 2008 18:35  |
Neil Hauge
Messages: 475
Registered: July 2009 |
Senior Member |
|
|
Hi Mike,
We do have plans to produce extender documentation, but we don't have much
in the way of that at the moment. My thought is that we will start
building this documentation on our Wiki, probably starting in the late May
time-frame.
There has been a decent amount of discussion on model usage on our
mailing-list, but a lot of this was based on our old model. But, in case
it helps, you could scan through the archives here -
https://dev.eclipse.org/mailman/listinfo/dali-dev.
Beyond that, you have made a discovery related to building JPA tooling,
and that would be the fact that it is very complicated, and requires a
large and complicated model to provide value in the tool. Add in the
requirement of extensibility, and things really get complicated. : )
Taking your example from below, it is very possible that you would need to
look at and understand all of the classes mentioned below to achieve what
you are trying to do.
We will be here in the meantime to try and answer general and specific
questions related to extension. At the very least, it will help us get
our documentation started.
Neil
Mike Yawn wrote:
> I'm just wondering if the team has any plans to produce some sort of
> document specifically targeted at extenders, rather than users, of Dali.
> I mention this because I'm feeling somewhat lost in the inheritance
> hierarchy at the moment. There's just a tremendous amount of code to
> read and digest here to try to understand where to tie in; some sort of
> high-level overview of the model, and rough sketch of the implementation
> approach, might really help.
> For example, because we added an attribute to the @Table annotation for
> our own use, I need to be able to make corresponding extensions so that
> our Dali platform can generate the additional attribute and parse it
> back. Just trying to find all of the classes and interfaces that might
> be related is daunting . .
> TableAnnotation
> TableImpl
> NullTable
> NullBaseTable
> AbstractResourceTable
> core.context.Table
> db.Table
> GenericJavaTable
> AbstractJavaTable
> JavaTable
> TableComposite
> and that's not including the helpers, superclasses and interfaces that
> aren't specific to the Table implementation, but are obviously critical
> to understanding the overall design -- like
> JpaContextNode, JavaJpaContextNode, JpaNode, Model
> AbstractJavaJpaContextNode, AbstractJpaContextNode, AbstractJpaNode
> JavaResourceNode, AbstractJavaResourceNode
> DeclarationAnnotationElementAdapter, AnnotationElementAdapter
> PropertyAspectAdapter, PropertyValueModel, WritablePropertyValueModel
> AspectAdapter
> If there's anything that might serve as an introduction to all this (and
> it's something you're willing to share), please let me know.
> Otherwise I'll keep plugging away with the trial-and-error . . .
> Mike
|
|
|
| Re: Any guidelines (now or planned) for extenders? [message #434871 is a reply to message #434867] |
Wed, 16 April 2008 19:50 |
Mike Yawn
Messages: 50
Registered: July 2009 |
Member |
|
|
I'll check though the mailing list archives and see what I can glean
from that. In the meantime, let know if you have any suggestions about
how to approach what I'm working on right now.
We have an extended version of several of the JPA annotations. I think
Hibernate follows a similar pattern of having 'enhanced' versions of the
annotations; I'm not sure if other implementors do something similar.
For example, we have added an 'alias' attribute to the @Table
annotation. Since we can't modify javax.persistence.Table, we've
created a parallel universe version that includes our attribute. The
user is then free to use either of the following, which are equivalent:
@javax.persistence.Table(name="catalog")
@com.ebay.persistence.Table(alias="cat")
@Entity
public interface Catalog { ... }
or
@com.ebay.persistence.Table(name="catalog", alias="cat")
@Entity
public interface Catalog { ... }
So I'm trying to figure out the best way to handle this in Dali. I'd
like to have the same flexibility -- where there might be a JPA @Table
annotation, or an eBay table annotation, or neither, or both.
But I'm willing to limit the flexibility -- especially initially - in
exchange for a cleaner implementation. I had started down a path where
we would always use the eBay annotation, since it is a superset of the
JPA annotation and thus would always work. But after ending up with
clones of a lot of classes, I'm wondering if I should reverse my
thinking here and say that for Dali compatibility, we will use only the
JPA annotation for the JPA-standard attributes, and will use the eBay
annotation only for the extended attributes. That still seems to have
me needing to handle seeing neither, both, or either of the @Table
annotations, but for any particular attribute, it will be associated
with only one annotation.
So I'm trying to figure out the best way to integrate the
com.ebay.persistence.Table annotation with Dali. Right now I've been
copying quite a few classes into my own hierarchy and modifying them to
support the additional annotation attribute (alias). I've got local
copies of:
Table, AbstractResourceTable, NullBaseTable, NullTable, TableImpl,
TableAnnotation
on the model side of things. I was just at the point of cloning Entity
since the Entity.getTable() method is returning the 'wrong' table, when
I started thinking about needing to re-evaluate the approach, and
probably rework all this so it better supports allowing either
annotation, rather than so strongly favoring the eBay variant.
On the UI side of things, things are currently broken; I have cloned
versions of JavaEntityComposite, AbstractEntityComposite, and
TableComposite, and the issue at present is that
AbstractEntityComposite.buildTableHolder() is getting a GenericJavaTable
from the subjectHolder and doesn't have any way to turn that into an
ebay TableImpl. So I'm thinking maybe the table holder needs to hold
both an eBay @Table and a JPA @Table, but I haven't really thought that
through yet.
I hope there's enough detail there to give a feel for the type of
modifications I'm attempting without including a bunch of irrelevant
stuff; I'm still new enough at this that it's not yet clear what is
important and what is not.
Thanks,
Mike
Neil Hauge wrote:
> Hi Mike,
>
> We do have plans to produce extender documentation, but we don't have
> much in the way of that at the moment. My thought is that we will start
> building this documentation on our Wiki, probably starting in the late
> May time-frame.
>
> There has been a decent amount of discussion on model usage on our
> mailing-list, but a lot of this was based on our old model. But, in
> case it helps, you could scan through the archives here -
> https://dev.eclipse.org/mailman/listinfo/dali-dev.
>
> Beyond that, you have made a discovery related to building JPA tooling,
> and that would be the fact that it is very complicated, and requires a
> large and complicated model to provide value in the tool. Add in the
> requirement of extensibility, and things really get complicated. : )
>
> Taking your example from below, it is very possible that you would need
> to look at and understand all of the classes mentioned below to achieve
> what you are trying to do.
>
> We will be here in the meantime to try and answer general and specific
> questions related to extension. At the very least, it will help us get
> our documentation started.
>
> Neil
>
>
> Mike Yawn wrote:
>
>> I'm just wondering if the team has any plans to produce some sort of
>> document specifically targeted at extenders, rather than users, of Dali.
>
>> I mention this because I'm feeling somewhat lost in the inheritance
>> hierarchy at the moment. There's just a tremendous amount of code to
>> read and digest here to try to understand where to tie in; some sort
>> of high-level overview of the model, and rough sketch of the
>> implementation approach, might really help.
>
>> For example, because we added an attribute to the @Table annotation
>> for our own use, I need to be able to make corresponding extensions so
>> that our Dali platform can generate the additional attribute and parse
>> it back. Just trying to find all of the classes and interfaces that
>> might be related is daunting . .
>
>> TableAnnotation
>> TableImpl
>> NullTable
>> NullBaseTable
>> AbstractResourceTable
>> core.context.Table
>> db.Table
>> GenericJavaTable
>> AbstractJavaTable
>> JavaTable
>> TableComposite
>
>> and that's not including the helpers, superclasses and interfaces that
>> aren't specific to the Table implementation, but are obviously
>> critical to understanding the overall design -- like
>> JpaContextNode, JavaJpaContextNode, JpaNode, Model
>> AbstractJavaJpaContextNode, AbstractJpaContextNode, AbstractJpaNode
>> JavaResourceNode, AbstractJavaResourceNode
>> DeclarationAnnotationElementAdapter, AnnotationElementAdapter
>> PropertyAspectAdapter, PropertyValueModel, WritablePropertyValueModel
>> AspectAdapter
>
>
>> If there's anything that might serve as an introduction to all this
>> (and it's something you're willing to share), please let me know.
>
>> Otherwise I'll keep plugging away with the trial-and-error . . .
>
>> Mike
>
>
|
|
| |
| Re: Any guidelines (now or planned) for extenders? [message #434874 is a reply to message #434872] |
Wed, 16 April 2008 22:15 |
Mike Yawn
Messages: 50
Registered: July 2009 |
Member |
|
|
Hi Karen,
Very good point on the issue of name collisions. I think our original
intent was to have the annotation processor flag as an error if both the
ebay annotation and the JPA annotation tried to set the same attribute,
but I think the implementation on that is lagging and is only happening
in a few instances.
I don't want to change the annotations entirely since we don't want to
break any existing installed base code, but since Dali integration is a
new feature for us, I think we can apply some stricter requirements
there. I will mark the JPA-standard attributes as @Deprecated within
our extended annotations and note that they won't work with Dali.
Since my last posting, I'm seeing that life would probably be simpler if
I maintained a 1:1 mapping between Model objects (the Table) and UI
objects (the TableComposite) -- it looks like it would be inelegant to
try to have my TableComposite build its content from two different Model
objects, one representing the JPA table and another the extended
attributes. So I may rework the UI separately to put the Alias in a
separate composite (currently it's stuck in between the table Name and
Catalog combos).
Thanks,
Mike
Karen Butzke wrote:
> Hi Mike,
>
> If you can still change the ebay annotation classes, I recommend against
> them being a superset of the javax annotations. How do you plan to
> handle this case:
>
> @javax.persistence.Table(name="catalog")
> @com.ebay.persistence.Table(name="cat")
> @Entity
> public interface Catalog { ... }
>
> Will you have overrides set up such that the ebay annotation "wins"?
> This is going to greatly complicate your life, based on our fun with
> implementing the orm.xml as an override of the java.
>
> Hibernate actually creates new annotations that are named the same, but
> they only include the new attributes. So you still have to use the
> javax annotations for name, catalog, schema in the case of Table. Then
> for alias you would use the ebay specific annotation.
>
> EclipseLink does not duplicate any annotation names from the
> javax.persistence package, but instead creates ones with new names. The
> benefit to this is not having to have fully qualified annotation names
> in your source. The Dali extension implementation would be similar for
> Hibernate and EclipseLink.
>
> I'll respond later with more information on a possible best way to
> approach your implementation (might depend on how much flexibility you
> have with changing your annotations). I wish we had some of the
> EclipseLink annotations done so you could see an example (and so our
> extension story would be more complete and less theoretical), but
> unfortunately we haven't had time for that yet.
>
> Karen
>
>
|
|
|
| Re: Any guidelines (now or planned) for extenders? [message #434888 is a reply to message #434872] |
Wed, 30 April 2008 17:06 |
Mike Yawn
Messages: 50
Registered: July 2009 |
Member |
|
|
Hi Karen,
You mentioned that you would follow up later with an approach for this
-- I'd be interested in hearing your thoughts if you get a chance.
(I've been away from doing the Dali integration work for a couple of
weeks working on other issues, but I'm going to be picking up this
effort again soon so any advice would be appreciated.)
I have deprecated the annotation attributes in our extended annotations
that shadow attributes of the standard JPA annotations, so that will
at least remove some of the issues.
Thanks,
Mike
Karen Butzke wrote:
> Hi Mike,
>
> If you can still change the ebay annotation classes, I recommend against
> them being a superset of the javax annotations. How do you plan to
> handle this case:
>
> @javax.persistence.Table(name="catalog")
> @com.ebay.persistence.Table(name="cat")
> @Entity
> public interface Catalog { ... }
>
> Will you have overrides set up such that the ebay annotation "wins"?
> This is going to greatly complicate your life, based on our fun with
> implementing the orm.xml as an override of the java.
>
> Hibernate actually creates new annotations that are named the same, but
> they only include the new attributes. So you still have to use the
> javax annotations for name, catalog, schema in the case of Table. Then
> for alias you would use the ebay specific annotation.
>
> EclipseLink does not duplicate any annotation names from the
> javax.persistence package, but instead creates ones with new names. The
> benefit to this is not having to have fully qualified annotation names
> in your source. The Dali extension implementation would be similar for
> Hibernate and EclipseLink.
>
> I'll respond later with more information on a possible best way to
> approach your implementation (might depend on how much flexibility you
> have with changing your annotations). I wish we had some of the
> EclipseLink annotations done so you could see an example (and so our
> extension story would be more complete and less theoretical), but
> unfortunately we haven't had time for that yet.
>
> Karen
>
>
|
|
| | |
| Re: Any guidelines (now or planned) for extenders? [message #610517 is a reply to message #434865] |
Wed, 16 April 2008 18:35 |
Neil Hauge
Messages: 475
Registered: July 2009 |
Senior Member |
|
|
Hi Mike,
We do have plans to produce extender documentation, but we don't have much
in the way of that at the moment. My thought is that we will start
building this documentation on our Wiki, probably starting in the late May
time-frame.
There has been a decent amount of discussion on model usage on our
mailing-list, but a lot of this was based on our old model. But, in case
it helps, you could scan through the archives here -
https://dev.eclipse.org/mailman/listinfo/dali-dev
Beyond that, you have made a discovery related to building JPA tooling,
and that would be the fact that it is very complicated, and requires a
large and complicated model to provide value in the tool. Add in the
requirement of extensibility, and things really get complicated. : )
Taking your example from below, it is very possible that you would need to
look at and understand all of the classes mentioned below to achieve what
you are trying to do.
We will be here in the meantime to try and answer general and specific
questions related to extension. At the very least, it will help us get
our documentation started.
Neil
Mike Yawn wrote:
> I'm just wondering if the team has any plans to produce some sort of
> document specifically targeted at extenders, rather than users, of Dali.
> I mention this because I'm feeling somewhat lost in the inheritance
> hierarchy at the moment. There's just a tremendous amount of code to
> read and digest here to try to understand where to tie in; some sort of
> high-level overview of the model, and rough sketch of the implementation
> approach, might really help.
> For example, because we added an attribute to the @Table annotation for
> our own use, I need to be able to make corresponding extensions so that
> our Dali platform can generate the additional attribute and parse it
> back. Just trying to find all of the classes and interfaces that might
> be related is daunting . .
> TableAnnotation
> TableImpl
> NullTable
> NullBaseTable
> AbstractResourceTable
> core.context.Table
> db.Table
> GenericJavaTable
> AbstractJavaTable
> JavaTable
> TableComposite
> and that's not including the helpers, superclasses and interfaces that
> aren't specific to the Table implementation, but are obviously critical
> to understanding the overall design -- like
> JpaContextNode, JavaJpaContextNode, JpaNode, Model
> AbstractJavaJpaContextNode, AbstractJpaContextNode, AbstractJpaNode
> JavaResourceNode, AbstractJavaResourceNode
> DeclarationAnnotationElementAdapter, AnnotationElementAdapter
> PropertyAspectAdapter, PropertyValueModel, WritablePropertyValueModel
> AspectAdapter
> If there's anything that might serve as an introduction to all this (and
> it's something you're willing to share), please let me know.
> Otherwise I'll keep plugging away with the trial-and-error . . .
> Mike
|
|
|
| Re: Any guidelines (now or planned) for extenders? [message #610518 is a reply to message #434867] |
Wed, 16 April 2008 19:50 |
Mike Yawn
Messages: 50
Registered: July 2009 |
Member |
|
|
I'll check though the mailing list archives and see what I can glean
from that. In the meantime, let know if you have any suggestions about
how to approach what I'm working on right now.
We have an extended version of several of the JPA annotations. I think
Hibernate follows a similar pattern of having 'enhanced' versions of the
annotations; I'm not sure if other implementors do something similar.
For example, we have added an 'alias' attribute to the @Table
annotation. Since we can't modify javax.persistence.Table, we've
created a parallel universe version that includes our attribute. The
user is then free to use either of the following, which are equivalent:
@javax.persistence.Table(name="catalog")
@com.ebay.persistence.Table(alias="cat")
@Entity
public interface Catalog { ... }
or
@com.ebay.persistence.Table(name="catalog", alias="cat")
@Entity
public interface Catalog { ... }
So I'm trying to figure out the best way to handle this in Dali. I'd
like to have the same flexibility -- where there might be a JPA @Table
annotation, or an eBay table annotation, or neither, or both.
But I'm willing to limit the flexibility -- especially initially - in
exchange for a cleaner implementation. I had started down a path where
we would always use the eBay annotation, since it is a superset of the
JPA annotation and thus would always work. But after ending up with
clones of a lot of classes, I'm wondering if I should reverse my
thinking here and say that for Dali compatibility, we will use only the
JPA annotation for the JPA-standard attributes, and will use the eBay
annotation only for the extended attributes. That still seems to have
me needing to handle seeing neither, both, or either of the @Table
annotations, but for any particular attribute, it will be associated
with only one annotation.
So I'm trying to figure out the best way to integrate the
com.ebay.persistence.Table annotation with Dali. Right now I've been
copying quite a few classes into my own hierarchy and modifying them to
support the additional annotation attribute (alias). I've got local
copies of:
Table, AbstractResourceTable, NullBaseTable, NullTable, TableImpl,
TableAnnotation
on the model side of things. I was just at the point of cloning Entity
since the Entity.getTable() method is returning the 'wrong' table, when
I started thinking about needing to re-evaluate the approach, and
probably rework all this so it better supports allowing either
annotation, rather than so strongly favoring the eBay variant.
On the UI side of things, things are currently broken; I have cloned
versions of JavaEntityComposite, AbstractEntityComposite, and
TableComposite, and the issue at present is that
AbstractEntityComposite.buildTableHolder() is getting a GenericJavaTable
from the subjectHolder and doesn't have any way to turn that into an
ebay TableImpl. So I'm thinking maybe the table holder needs to hold
both an eBay @Table and a JPA @Table, but I haven't really thought that
through yet.
I hope there's enough detail there to give a feel for the type of
modifications I'm attempting without including a bunch of irrelevant
stuff; I'm still new enough at this that it's not yet clear what is
important and what is not.
Thanks,
Mike
Neil Hauge wrote:
> Hi Mike,
>
> We do have plans to produce extender documentation, but we don't have
> much in the way of that at the moment. My thought is that we will start
> building this documentation on our Wiki, probably starting in the late
> May time-frame.
>
> There has been a decent amount of discussion on model usage on our
> mailing-list, but a lot of this was based on our old model. But, in
> case it helps, you could scan through the archives here -
> https://dev.eclipse.org/mailman/listinfo/dali-dev
>
> Beyond that, you have made a discovery related to building JPA tooling,
> and that would be the fact that it is very complicated, and requires a
> large and complicated model to provide value in the tool. Add in the
> requirement of extensibility, and things really get complicated. : )
>
> Taking your example from below, it is very possible that you would need
> to look at and understand all of the classes mentioned below to achieve
> what you are trying to do.
>
> We will be here in the meantime to try and answer general and specific
> questions related to extension. At the very least, it will help us get
> our documentation started.
>
> Neil
>
>
> Mike Yawn wrote:
>
>> I'm just wondering if the team has any plans to produce some sort of
>> document specifically targeted at extenders, rather than users, of Dali.
>
>> I mention this because I'm feeling somewhat lost in the inheritance
>> hierarchy at the moment. There's just a tremendous amount of code to
>> read and digest here to try to understand where to tie in; some sort
>> of high-level overview of the model, and rough sketch of the
>> implementation approach, might really help.
>
>> For example, because we added an attribute to the @Table annotation
>> for our own use, I need to be able to make corresponding extensions so
>> that our Dali platform can generate the additional attribute and parse
>> it back. Just trying to find all of the classes and interfaces that
>> might be related is daunting . .
>
>> TableAnnotation
>> TableImpl
>> NullTable
>> NullBaseTable
>> AbstractResourceTable
>> core.context.Table
>> db.Table
>> GenericJavaTable
>> AbstractJavaTable
>> JavaTable
>> TableComposite
>
>> and that's not including the helpers, superclasses and interfaces that
>> aren't specific to the Table implementation, but are obviously
>> critical to understanding the overall design -- like
>> JpaContextNode, JavaJpaContextNode, JpaNode, Model
>> AbstractJavaJpaContextNode, AbstractJpaContextNode, AbstractJpaNode
>> JavaResourceNode, AbstractJavaResourceNode
>> DeclarationAnnotationElementAdapter, AnnotationElementAdapter
>> PropertyAspectAdapter, PropertyValueModel, WritablePropertyValueModel
>> AspectAdapter
>
>
>> If there's anything that might serve as an introduction to all this
>> (and it's something you're willing to share), please let me know.
>
>> Otherwise I'll keep plugging away with the trial-and-error . . .
>
>> Mike
>
>
|
|
| |
| Re: Any guidelines (now or planned) for extenders? [message #610520 is a reply to message #434872] |
Wed, 16 April 2008 22:15 |
Mike Yawn
Messages: 50
Registered: July 2009 |
Member |
|
|
Hi Karen,
Very good point on the issue of name collisions. I think our original
intent was to have the annotation processor flag as an error if both the
ebay annotation and the JPA annotation tried to set the same attribute,
but I think the implementation on that is lagging and is only happening
in a few instances.
I don't want to change the annotations entirely since we don't want to
break any existing installed base code, but since Dali integration is a
new feature for us, I think we can apply some stricter requirements
there. I will mark the JPA-standard attributes as @Deprecated within
our extended annotations and note that they won't work with Dali.
Since my last posting, I'm seeing that life would probably be simpler if
I maintained a 1:1 mapping between Model objects (the Table) and UI
objects (the TableComposite) -- it looks like it would be inelegant to
try to have my TableComposite build its content from two different Model
objects, one representing the JPA table and another the extended
attributes. So I may rework the UI separately to put the Alias in a
separate composite (currently it's stuck in between the table Name and
Catalog combos).
Thanks,
Mike
Karen Butzke wrote:
> Hi Mike,
>
> If you can still change the ebay annotation classes, I recommend against
> them being a superset of the javax annotations. How do you plan to
> handle this case:
>
> @javax.persistence.Table(name="catalog")
> @com.ebay.persistence.Table(name="cat")
> @Entity
> public interface Catalog { ... }
>
> Will you have overrides set up such that the ebay annotation "wins"?
> This is going to greatly complicate your life, based on our fun with
> implementing the orm.xml as an override of the java.
>
> Hibernate actually creates new annotations that are named the same, but
> they only include the new attributes. So you still have to use the
> javax annotations for name, catalog, schema in the case of Table. Then
> for alias you would use the ebay specific annotation.
>
> EclipseLink does not duplicate any annotation names from the
> javax.persistence package, but instead creates ones with new names. The
> benefit to this is not having to have fully qualified annotation names
> in your source. The Dali extension implementation would be similar for
> Hibernate and EclipseLink.
>
> I'll respond later with more information on a possible best way to
> approach your implementation (might depend on how much flexibility you
> have with changing your annotations). I wish we had some of the
> EclipseLink annotations done so you could see an example (and so our
> extension story would be more complete and less theoretical), but
> unfortunately we haven't had time for that yet.
>
> Karen
>
>
|
|
|
| Re: Any guidelines (now or planned) for extenders? [message #610528 is a reply to message #434872] |
Wed, 30 April 2008 17:06 |
Mike Yawn
Messages: 50
Registered: July 2009 |
Member |
|
|
Hi Karen,
You mentioned that you would follow up later with an approach for this
-- I'd be interested in hearing your thoughts if you get a chance.
(I've been away from doing the Dali integration work for a couple of
weeks working on other issues, but I'm going to be picking up this
effort again soon so any advice would be appreciated.)
I have deprecated the annotation attributes in our extended annotations
that shadow attributes of the standard JPA annotations, so that will
at least remove some of the issues.
Thanks,
Mike
Karen Butzke wrote:
> Hi Mike,
>
> If you can still change the ebay annotation classes, I recommend against
> them being a superset of the javax annotations. How do you plan to
> handle this case:
>
> @javax.persistence.Table(name="catalog")
> @com.ebay.persistence.Table(name="cat")
> @Entity
> public interface Catalog { ... }
>
> Will you have overrides set up such that the ebay annotation "wins"?
> This is going to greatly complicate your life, based on our fun with
> implementing the orm.xml as an override of the java.
>
> Hibernate actually creates new annotations that are named the same, but
> they only include the new attributes. So you still have to use the
> javax annotations for name, catalog, schema in the case of Table. Then
> for alias you would use the ebay specific annotation.
>
> EclipseLink does not duplicate any annotation names from the
> javax.persistence package, but instead creates ones with new names. The
> benefit to this is not having to have fully qualified annotation names
> in your source. The Dali extension implementation would be similar for
> Hibernate and EclipseLink.
>
> I'll respond later with more information on a possible best way to
> approach your implementation (might depend on how much flexibility you
> have with changing your annotations). I wish we had some of the
> EclipseLink annotations done so you could see an example (and so our
> extension story would be more complete and less theoretical), but
> unfortunately we haven't had time for that yet.
>
> Karen
>
>
|
|
| | |
Goto Forum:
Current Time: Fri Apr 26 03:42:32 GMT 2024
Powered by FUDForum. Page generated in 0.04887 seconds |
] 
Search
Help
Register
Login
Home
