NHibernate cascade and generated guid ids - why are they not generated for the children on save?

Question

I do the following:

    var @case = new Case
    {
        Name = "test"
    };

    // User is persistent and loaded in the same session
    User.AddCase(@case); // sets @case.User = User too
    Session.Update(User);

    response.CaseId = @case.Id;

The cascade on User.Cases is set to All. But @case.Id is not set until the transaction is committed. Is that expected behavior? I would very much like to get the Id before committing. Can it be done?

Answer 1

have you tried Session.SaveOrUpdate(User)? Although i must say that cascaded operations do not take place until needed and that happens on flush/commit. when you Session.Save(@case) you are not flushing/commiting

Having said that you are making a logical mistake: by creating @case you are not updating the User. The user is a separate entity and Case has a foreign-key to User. So saving the Case is proper, and the List of cases a User is just association information

Answer 2

A more pure DDD'y feely thing would probably be to model both User and Case as aggregate roots and then model their relationship with a role object RelatedCase (that's aggregated inside User and thus should be cascade="all-delete-orphan").

Aggregate roots should be saved in repositories, which (if you delegate the call to session.Save(...)) will give you the id you need at a time where you can use it.

Then the role can (and in my experience often will, at least after some time) contain extra information that characterizes the relationship, and does not belong on neither on the user nor on the case. Let's say the relationship keeps track on why the user and the case are related.

This way your code could look like this:

var case = caseFactory.Create("name");
caseRepository.Save(case);

user.AssignCase(case, "Assigned by some dude");

-and inside AddCase:

public void AddCase(Case case, string reason)
{
    cases.Add(new RelatedCase(case, reason));
}

This is in my opinion the prettiest way to model this kind of thing, but you will of course be penalized a little bit performance-wise. If a pretty model is more important to you, then you should go for something like this.