I'm very junior in o/r mapping and persistent object tools.
But I love very NHibernate. It helpes me very in the project I do.

One thing which torments me is that NHibernate if I correctly understood is the_static_o/r library it doesn't allow changing the structure of classes and relations dynamically.

But in many cases project require this feature.

I read something about data scheme classes in original Java Hibernate,
but nothing found in NHibernate (if it is in NH please write me).

I think that is not a problem - to change attributes of c# classes dynamically or maybe to switch to classes with collections of dynamic properties.

My post is generally not a question but attemt to discuss the question of dynamically changing of data scheme in NHibernate.

Sergey

Hi,

I am initiating a new project ERP and we go to need this. I am with the same questions. :(


[]s

We can't find a solution when there is no problem...

Do you have a specific case where you need this "feature" ?

Hi,

Sample:
For standard, my system has two fields: Name and ID. But my user wants another field called DateSaved. Then I need to leave the system customisable for this situation. Clearly that this is a possible simpler example. But in the case of a great ERP system this is highly necessary. This type of system has as characteristic basic the customisation for each customer.
Some form to use NHibernate in this way?

[]s

* Sorry my bad english.

I still don't see the problem; here, you have to:

- Add a column in the database
- Add a field+property+logic to the entity
- Add the Mapping
- Update the UI
- Compile & Deploy

The problem is in the last part. The system already is running in the customer. I cannot compile. Necessary to leave an interface where it can create fields without to be necessary the compilation.

Well, I can't figure out how you can make the changes available without creating a new SessionFactory (which means that customers will be disconnected; so that's like rebooting the system)

Instead of storing each column data for the "customizable" objects in an instance field you store them all in a IDictionary, this way you can have a static mapping and a normal compiled object for handling the data.

Even if you could have a dynamic mapping (which you could if you dont mind generating part of the mapping and recreating the factories) you would not be able to take advantage of having properties for each "column" anyways because you would have to compile the classes on runtime to be able to create properties in them..

So its better to just use a IDictionary directly if you want to allow the users of the system to create more fields for your object.