+1 to solution 1. But man it's verbose! I'd rather use the xml files instead
;-)

Ara.

> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:hibernate-devel-
> [EMAIL PROTECTED] On Behalf Of Emmanuel Bernard
> Sent: Saturday, May 01, 2004 2:58 PM
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Hibernate] Annotated collections
> 
> 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
> 
> 
> --
> Emmanuel Bernard
> [EMAIL PROTECTED]
> http://www.hibernate.org
> 
> 
> 
> -------------------------------------------------------
> 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

Reply via email to