Hello,

We have a table element that has two columns

element_type varchar(1)
and
element_subtype integer

defining the class of a row ( a row with types [a,1] has a class different from a row with types [a,2]...).

As you can imagine, this is a given design that cannot be changed.
What could be a possible mapping of this table to hibernate?

My study of the hibernate dtd showed, that discriminator allows just one column. (<!ELEMENT discriminator (column?)>) Is there any hope for us?

Salut Thomas

No hope.
But you could try to do a patch on that.

Merci for the answer. I think, that the solution will be, not to map the class hierarchy in the persistent classes at all. The class hierarchy will be represented just in the value objects.

Salut, Thomas

....but on the other hand, writing this patch would be an good opportunity to enter into hibernate source code.

Let's say I would write a patch. This patch would imply minor changes in very basic classes, I suppose. And a change in the mapping dtd. Would this patch be accepted and integrated into future hibernate releases ?

More general:

If I would like to implement a new feature for hibernate, but only under the condition, that there is a good chance, that my code is integrated in future releases of hibernate?

Which formal steps do I have to proceed?

Any coding conventions?

Any testing conventions?

And in the end I have to submit the patch to jira, and if it is written correctly it will be integrated into future releases, true?

Salut, Thomas[/quote]

No promises. Depends how upon elegantly it was implemented, and upon whether the extra complexity was "worth it".



There is no formal procedure. It helps to propose new functionality to the devel list first, just to check that we think it is not a Bad Idea.



There is a checkstyle ant task



New functionality should be accompanied by unit tests, of course. The test should extend net.sf.hibernate.test.TestCase



Only if we like it. :)

Hello Gavin,

of course you do not want to guarantee anything. But you must also understand my point of view. I don't want to write something, if from the there is no chance that it enters the code.

So for my concrete case, please encourage me("Yes Thomas, if you do that thing in an elegant way, there is a good chance, that it enters") or discourage me ("This change wil affect much too basic classes, and I cannot imagine, that you can do this in a acceptable way.")

Salut, Thomas

Well, its an existing feature request that has not been rejected, so it is something we will certainly consider. My main concern is how discriminator values are assigned to transient (and detached) instances. I guess a new Interceptor callback could solve that one.

Note that you should work against the v22branch for this kind of new functionality.

Hi,

What is the evolution ? The posts below are quite olds, Is it now a way to use multiple discriminator columns to do the inheritance mapping ?

My problem is exactly the same as rimmele7...

I saw a few swiss people on this forum, I live in Geneva and my english is very limited, so if a compatriot would help me in french, please contact me : lilian dot robert at gmail.com