collection key is always derived from ID property?

so columns specification is only for composite ID's,
to allow column mapping different from composite id mapping?

HIbernate is able to guess ( cook ) correct set of columns in any
case, even for composite ID?

The types of the collection <key> can be derived from the referenced PK. The column names themselves cannot,

But not for default case?
So I can just use <key/>even for composite PK , and let hibernate to the job?

no, the column names are always required

OK, this complicates composite ID mappings a little...

Yes, composite id stuff is hard with xdoclet.

well, it seems to me that DTD ( which I'm basing new plugin upon )
is somehow not logical.

For example, index requires type only if used in map... Kind of uncool.

Would it be more logical, if there is
<index> which is always primitive and composite index,
which eats class name ( ok, I know, there is composite index already
which defines ternary assoc )

At the moment it's unclear to me, what index with several columns means in context of map ( or list... )

It makes sense for a map, since you might have a multi-column custom type.

Granted, it is not needed for a list.

This woule mean:
- We need tags to define custom type....
and xdoclet is not aware of those custom types. right now.

And it would be almost impossible to integrate custom type not awailable as source at build time...

And also that xdoclet2 would be unable to say to user that he
is pretty wrong with his columns. Somehow uncool....

And index for the list is always int?

Eh? XDoclet doesn't need to be aware of the custom types....

its just: type="MyUserType"

XDoclet just passes that straight thru.




I don't think it is XDoclet's responsibility to validate this.




Yes.

Fine. less work for me.


Then index tag is not necessary for list at all...

The index element is needed, in order to define the column name.