Your questions first: yes - I would think the compositional way is best - mainly because it would mimic the hbm.xml way of declaring things.
Then now my complaints ;)
I must say that these annotations for sure is very verbatim and IMHO clogs up the code - but hey, that's just me ;)
...but I can see the advantages of having this stuff in the code and do support it, but I for sure never hope it will be the only way of doing things ;) (I know we will keep hbm.xml's,
but now EJB3 also praises the annotation spec and I just see a new "descriptor"..oh - "annotation" hell/wave raising in the horizon.)
And does anyone know why the JSR haven't included stuff like inheritance/composition in the spec ?
It smells that the expressiveness of both the actual annotations (the @-tags) and the underlying implementation (the stuff that is needed to support the @-tags) have
to rely on "copy-paste"/structural reuse....
Nuff' complaining - I still think compositions is the way to go ;)
/max
Emmanuel Bernard wrote:
Note that the 'used' param is not... used / visible in a correct annotation usage.
Emmanuel Bernard wrote:
OK here are more details.
Here is a typical correct annotation in the solution 1 @Map( @Index( type = "String" ), @Element( type="String" columns = { @Column( name = "FLD_ELT" ) } ), @Key ( columns = { @Column( name = "PARENT_ID" ) } ), table = "CHILDREN", lazy = true, batchSize = 10, cache = CacheUsage.NonStrictReadWrite ) Map getChildrens() { return childrens; }
Here is a typical correct annotation in the solution 2 @Map( @Key ( columns = { @Column( name = "PARENT_ID" ) } ), table = "CHILDREN", lazy = true, batchSize = 10, cache = CacheUsage.NonStrictReadWrite ) @Index( type = "String" ) @Element( type="String" columns = { @Column( name = "FLD_ELT" ) } ) Map getChildrens() { return childrens; }
Here is a typical *incorrect* annotation in the solution 1 that will be detected at Runtime
@Map(
@Index(
type = "String"
),
@CompositeElement(
//detailed annotation here
),
@Element(
type="String"
columns = { @Column( name = "FLD_ELT" ) }
),
@Key ( columns = { @Column( name = "PARENT_ID" ) } ),
table = "CHILDREN",
lazy = true,
batchSize = 10,
cache = CacheUsage.NonStrictReadWrite
)
Map getChildrens() {
return childrens;
}
Incorrect annotation can easily be build for solution 2.
What is ugly is the way the annotation class is written and thus its JavaDoc
public @interface Map { /** * Map index. Default not used. */ Index index() default @Index( used = false ); /* used=false means the default value is considered not * to be the colelction index. * Note that default value for used in @Index is true * So real user don't care about this value which is an * impelmentation detail */
/**
* Element. Default not used.
* Element and CompositeElement are mutually exclusive, only one per Collection
* should have used = true
*/
Element element() default @Element( used = false, type = "N/A" );
/**
* Composite Element. Default not used.
* Element and CompositeElement are mutually exclusive, only one per Collection
* should have used = true
*/
Element element() default @CompositeElement( used = false, ...);
// .... }
From a user perspective, the solution 1 is fine except for this 'used' paramteter that should be hidden in a good solution.
Max Rydahl Andersen wrote:
Hi Bernard,
I'm not totally fluent in JSR-175, yet - so I would very much appreciate if you could give a more "full" example....something where you show the complete method/class declaration (just the declaration, not the body) - then I would have a much better grasp on what you're asking for - and hence provide a better answer ;)
Sorry for being non-fluent in annotations yet ;)
/max
Emmanuel Bernard wrote:
I'm working on collection annotations right now, and I don't like the way it goes.
Since now I managed to annotate using composition for dependent annotation
@Id (
@Generator(
@Param[]
)
)
And I strongly believe it's the best way to do.
But for collections, this is more complex. There should be something like
@Map (
@Index(),
@OneToMany()
)
The problem is that Index can be CompositeIndex, IndexManyToMany etc
And OneToMany can be Element, ManyToMany etc and each of these annotations structure are different.
2 solutions so far:
- Declare all kind of indexes inside Map and let the user set 1 of these (other will have a default 'not used' value)
- Use the XDoclet way and put Map, Index etc flatten in the property.
Remember that Annotation cannot be inherited and annotations does not support some kind of (Index|CompositeIndex) like DTD does.
The first one is a bit ugly but keep the composition way to do, and is in my opinion much more readable when writing a metadata annotation for a class. Of course a user could set 2 index or 2 elements in the same Annotation, this should e checked at runtime.
The second one is ugly too. I've always found flatten XDoclet way too complex: people never know which one to put together. And it does not prevent the 2 indexes in the same annotated element issue.
Unfortunatly, due to Annotation flaws, neither can be ckecked at compile time (at least I've not found how). But it'll be much simplier for me to ckeck that at compile time in the first solution.
I plan to go the the composition way. Any comment, vetoe?
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
hibernate-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
_______________________________________________
hibernate-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/hibernate-devel
