It is of course less verbose than xml files : most default values should fit common needs and more attributes are inferred compared to hbm files.

Ara Abrahamian wrote:

+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



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

Reply via email to