Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I have some classes in my app that don’t require an ID to be persisted. These could be things like user logs or audit records. I can add an arbitaty id to them but I would like to avoid that as they don’t mean anything.
The retrieval of these objects is always on another key (like UserId) which is not unique to the record.
Because NHibernate deals with entities, you must have something that identifies the entity. It is best to have a separate unique id field as that is the way the NHibernate is designed to work and it is much easier not to fight it.
However, if you have design constraints where you really can’t have a separate id column, you can use a composite-id defined on existing fields. For example, for an audit log record you might use a combination of a UserId and a DateTime. If the records are only written once and not ever manipulated (e.g. audit log), you should also add mutable=false to the class mapping to enforce that. Also, be aware if you do use a composite-id like this it will likely cause issues if you ever try to use some of NHibernate’s more advanced features with this entity in the future.