Hi there !

As an example, I would like to try a dependent object : a kind of String.
Let's call that object Text (it use a String internaly).

When I want to use a Text, I have to use :

First question : what do you think about mixing @Column and @dependent ?
Is it correct ? I can't find other ways to specify the updatable status without @Column. On the other hand, why should I provide since it is already provided inside the @dependent...

Second question, here is the code the the Text class :


Why should I use the @DependentObject ? I would love not to have to annotate that class. When I had used the Text attribute, it was mandatory to provide bolide.type.Text, so that sound like redundant information.

As I do not have to modify the String class itself it I woulld use it as a persistent attribute, I wonder why I should modify my own String class (here Text) ?

thanks !

I think I have an answer to my first question ;-)

Instead of using two annotatation, use only one like that :


Correct ?

For the 2nd question @Dependent is optional, you don't always have to override component columns.
So @DependentObject is mandatory.

In fact, that's I don't understand.
@Dependent is for the "business persistent object" while
@DependentObject is for the "new type object" like Text for a kind of String.

If I tell in my business object that an attribute is @Dependent on p.Text,
then, we should assume that p.Text is in the classpath and is persistent on FIELDS that are not transient for examples.

So, by default, it should be optional to modify the p.Text by adding annotations in it. I would like to be able to use p,Text from "outside" (I mean by otuside that I can't modify it).

Of course I talking of default, if one want to customize default and annotate p.Text, then it should be possible.

I would like to understant what lead the decision to make @DependentObject mandatory and @Depend optional ?

Also, as a discussion, what do you think of the reverse way o doing that : @Dependent would become mandatory and @DependentObject optional ?

How to you handle the types that would came from "outside" ?
In fact, we do not have to annotate String to be able to use it as an attribute in a business object ...

Thanks !

A dependent object is not a type. It is a component in the Hibernate language.
@Dependent is a commodity for overriding
I know it looks more cool to use @Dependent, but don't be blind ;-)
We choose this way to avoid redundency. Like Strings I don't want to have to declare a component as persistent in the classes that use it.

The common usage is



Actually @Dependent has been added to work around a common issue in XDoclet where component columns were not overridable.

It is like all you said goes to the direction I talked about or I missed something. Your example is a perfect example of types or component.


I agree not to declare String persistent in clasees that use it, but I may use @Column for a String in the classe that use it. In both cases (with or without @Column) I will not have to change anything to the String class to be able to use is in another object.

So, the question is still there : why is it mandatory to modify Adresse component ?

You said

Nothing to do with cool or not, I would like to be able to use components from other project that I will not be able to change or that I don't want to change.
I said that because one solution could be inheritance :



So, the question is what is the added value of the sub-class here ?
What does @DependentObject annotation change that could not be done without the annotation ?

Don't misunderstand my goal, I'm happy with Hibernate, I just want to understand how annotation works (including their limit if any).

Once again, because a component is *not* a type.
A component can have associations (many to one or collections)... We're not talking about columns only.
A component is much more an entity than a type. So see @DependentObject much like @Entity.
If you need to reuse "sealed" classes, you'll be able to do it through the XML deployment descriptor

I've missed that point.

Unfortunatly, I would like to rely only on annotations.
Is there a solution that would help me to use sealed classes ?

What about having default option for annotation that would make use of component as type without having to modify it ?

For example, if you use

then, bolide.type.Text would not have any annotation but no way to have assiciations inside Text also.
If you need a real component and not a type, then you would have to annotate on both side.

Thanks for your light !

You can't practically use annotations on sealed classes, consider xml configuration for them.

Note that allowing composite user type through annotations is on my road map.