Hi,

is it possible that someone implements the following approach to solve the "discriminator problem"?

Idea 1: "Implicit discriminator columns"
If a table has an Int32 column with a default name (e.g. "classID") (the default name could be defined in one of the usual config files) NH should consider this column automatically as an implicit discriminator column.
[Goal: avoid discriminator specifications in the *.hbm.xml files at all]

Idea 2: "Automatic discrimator values"
The value to be written into the discriminator column for a concrete class should be determined by NHibernate itself.
[Goal: the discriminator values need not to be defined in the mapping files.]

Class registry:
For the purpose of assigning an Id to every class there could be a table (with a {globally configurable} default name, e.g. "Hibernate_Persistent_Class") in the same data base (!). This table would play the role of a "class registry".

Automatic class registration:
If NHibernate needs to insert an object, it first looks up the id for this class in its internal cache of table "class registry".
If the class (name and namespace) is not found in the cache, the "class registry" table is locked for write and the cache is refreshed.
If the class is not found in the refreshed cache, then NH registers the class, i.e. inserts a row with class name and namespace in "Persistent_Class" and assigns an ID.

[The namespace can be stored as a string - or as an Integer foreign key into a "Hibernate_namespace" table.]

NH then uses this class ID - as usual - to fill the field in the discriminator column of the row inserted for the instance (of the corresponding class).

Invariant:
For every object stored in the data base its classID value is already registered.

Special case:
If NH reads a classID value (from the data base) which it has not in its own "class registry" table cache, then NH must refresh its cache.
This case can happen when another, concurrently running application has inserted an object in the meantime (i.e. since the last cache refresh).
But if this other application uses the same procedure as describes above, it always registers the object's class before inserting the object itself (if not someone else did the registration already before), hende the classID is in the refreshed cache.

Regards,
Mick

Maybe you could describe first what the "discriminator problem" actually is?

Idea 1 is not implementable because NHibernate does not look at the table schema when reading mapping files.

Idea 2 is not implementable because there is no clear stable and universally acceptable algorithm to map types to integers.

Class registry and automatic class registration seem to be aimed at a problem that is only specific to you. Why do you think it would be useful for NHibernate to support this?

Thanks for your response and
thanks for your active role in the NHibernate project first.

Problem:
I have a table with is used to store the instances of many different subclasses of a class ValueObject. When I create a new subclass (with no additional instance variables), I don't want to modify the mapping file. The subclass should be stored according to the superclass mapping.
And the discriminator value for the subclass should be assigned from NH automatically. So there is nothing new to say in the mapping file.

Idea 1 (Version 2):
In the *.hbm.xml file the use of a discriminator column is explicitly declared as usual.
But the value is not specified explicitly in <class> and <subclass> elements. Rather it is specified that the discriminator value is determined automatically by NH, e.g. :



The value of attribute "discriminator-auto-value" is a symbolic name for the registry. In a config file the symbolic name is associated with the name of the concrete "class registry" table.

Idea 2 : The id assigned to a class is simply the next free id (e.g. using a separate hilo table for class ids).
This means the assignment of the class id-s to the classes depends on the order in which the classes are registered.

Hence the same class can have different class id-s in different data bases.
But this doesn't matter, because the mapping class -> id is read from the data base at runtime from the concrete data base (from the "class registry" table).

Regards,
Mick[/code]