How to map a request response behavior

Question

I'm facing some issues trying to model my business logic using NHibernate Fluent mapping.

I've a entity model like this:

public class Request
{
    ...
    public virtual Response Response {get; set;}
}

public class Response
{
    ...
    public virtual Request Request {get; set;}
}

My Request entity should be able to exist without a Response entity, and vice versa my Response entity should be able to exist without a Request. Can this be mapped as a one-to-one mapping? I know that is seems wired that a Response can exist without a Request, but that could happen in my situation.

I have read the article I Think You Mean a Many-to-one, Sir, but I still think that a many-to-one mapping is not the right thing for me, as none of my entities should have a list of either Responses or Requests.

How should this situation be mapped?

EDIT 1

My Fluent map using the foreign key association from How to do a fluent nhibernate one to one mapping?:

public RequestMap()
{
    Id(x => x.Id).GeneratedBy.Guid();
    References(x => x.Response, "ResponseId").Unique().Cascade.All();
}

public ResponseMap()
{
    Id(x => x.Id).GeneratedBy.Guid();
    HasOne(x => x.Request).Cascade.All().PropertyRef(x => x.Response);
}

This seems to work in many situations, but when I try to add multiple Request entities without a reference to a Response entity, I get this error:

System.Data.SqlClient.SqlException : Violation of UNIQUE KEY constraint 'UQ__Request__346FA94719588CEC'. Cannot insert duplicate key in object 'dbo.Request'. The duplicate key value is (). The statement has been terminated.

EDIT 2

public RequestMap()
{
    Id(x => x.Id).GeneratedBy.Guid();
    HasOne(x => x.Response).Cascade.All().PropertyRef(x => x.Request);
}

public ResponseMap()
{
    Id(x => x.Id).GeneratedBy.Guid();
    References(x => x.Request, "RequestId").Cascade.All();
}

Using this mapping, the mapping between the objects is not persisted when doing request.Response = response;. Should I make this setter protected?

score 1 · Answer 1 · edited May 23 '17 at 12:22

1

I might have misunderstood the question, but this seems to require you to map one of the entities with "References" and the other one with ">Inversed< References".

Please have a look here How to do a fluent nhibernate one to one mapping?

edited May 23 '17 at 12:22

Community

1
1

answered Dec 17 '13 at 19:55

migajek

8,524
15
77
116

Which of these solutions do you think I should use? *Primary key association* or *Foreign key association*. I do not think that the *Primary key association* would work, as neither the `Response` always has a `Request` or the `Request` has a `Response` -- and therefore the `Id(x => x.Id).GeneratedBy.Foreign("Setting")` cannot be used. – dhrm Dec 17 '13 at 20:52
I was thinking of Foreign Key association – migajek Dec 17 '13 at 21:01
1

Please see my `EDIT 1`. – dhrm Dec 17 '13 at 21:13

score 1 · Accepted Answer · answered Dec 18 '13 at 04:05

The issue with your EDIT 1 comes from these facts:

The Request table does have a unique constraint over the column "ResponseId". I.e. each row must have different value
The Requests stored without reference to Response do have NULL instead of any value... all of them. And that breaks the above requirement to have each row unique

Solution in this case would be to remove the unique key on the DB level from the ResponseId column. Because this is what we need (Request without Response). I.e. few concurrent NULL values in ReponseId should be allowed.

But what is a bit confusing me, is the naming: Reponse/Request

It seems to me, that Request (from my web development experience) is the trigger, the first one. And if all goes ok, there is a Response sent back. Should not your mapping be inversed? That the Response table contains the RequestId?

I've seen this statement in the question:

My Request entity should be able to exist without a Response entity, and vice versa my Response entity should be able to exist without a Request

Well, so ... let's assume that: the Response can NOT live without the Request... then your mapping (but inversed) should work even with the Unique key constraing.

And what is even more important, then the pure one-to-one mapping will work, because these two can share the Primary key (generated by Request, consumed by Response)

Thanks for your reply. I think you are right; the mapping should be inversted. Do not mind the wired situation, where a response can live without a request. That because I receive responses on others requests. Please see my new mapping i `EDIT 2`. — dhrm, Dec 18 '13 at 06:48
In general, almost always, it is better to set both sides of the relationship. `request.Response = response; response.Request = request;` If I read it correctly, now we are saying the the relationship goes via the `Request` property of the *Response*. So we should be sure, that this reference is set — Radim Köhler, Dec 18 '13 at 06:53

How to map a request response behavior

2 Answers2