NHibernate References NotFound.Ignore()

[Mo Sarwar]

In my mapping for a table H when using References(x => x.E).Column("E_Code").Nullable().NotFound.Ignore();  from one table (H) to another table (E), to give me a many to one relationship I get a query for each instance where the E_Code in the H table does not exist in the E table. How can I reduce the number of queries but still have E set to null if there is no match?

[Oskar Berggren]

This is the way it works at the moment. I believe there are older
posting and open issue reports in jira on this.

/Oskar

> --
> You received this message because you are subscribed to the Google Groups
> "nhusers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/nhusers/-/hHEv4Dp7hf0J.
> To post to this group, send email to nhu...@googlegroups.com.
> To unsubscribe from this group, send email to
> nhusers+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/nhusers?hl=en.

[StuS]

Is that to say there is no way around this issue? This essentially creates the N+1 bug everyone suggest to circumvent..

Thanks

On Thursday, April 19, 2012 12:15:59 PM UTC+1, Oskar Berggren wrote:

This is the way it works at the moment. I believe there are older
posting and open issue reports in jira on this.

/Oskar

Den 18 april 2012 11:28 skrev Mo Sarwar <>:
> In my mapping for a table H when using References(x =>
> x.E).Column("E_Code").Nullable().NotFound.Ignore();  from one table (H) to
> another table (E), to give me a many to one relationship I get a query for
> each instance where the E_Code in the H table does not exist in the E table.
> How can I reduce the number of queries but still have E set to null if there
> is no match?
>
> --
> You received this message because you are subscribed to the Google Groups
> "nhusers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/nhusers/-/hHEv4Dp7hf0J.
> To post to this group, send email to nhu...@googlegroups.com.
> To unsubscribe from this group, send email to

> nhusers+unsubscribe@googlegroups.com.

[Oskar Berggren]

If at all possible, cleaning the database is the preferred way.

/Oskar

>> > nhusers+u...@googlegroups.com.

>> > For more options, visit this group at
>> > http://groups.google.com/group/nhusers?hl=en.
>

> --
> You received this message because you are subscribed to the Google Groups
> "nhusers" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/nhusers/-/e4TQi7EmxXIJ.

>
> To post to this group, send email to nhu...@googlegroups.com.
> To unsubscribe from this group, send email to

> nhusers+u...@googlegroups.com.

[StuS]

Thanks  -We'll keep that in mind,

However, after some research, we've discovered, it's probably less of a problem than we think... as the occurance of "dodgy" data is to be minimal - so, yes, cleaning the data would sort this.

We were under the impression that it would query the data, even if, the field was null (It won't)

On Thursday, April 19, 2012 4:27:15 PM UTC+1, Oskar Berggren wrote:

If at all possible, cleaning the database is the preferred way.

/Oskar

>> > nhusers+unsubscribe@googlegroups.com.

>> > For more options, visit this group at
>> > http://groups.google.com/group/nhusers?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "nhusers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/nhusers/-/e4TQi7EmxXIJ.
>
> To post to this group, send email to nhu...@googlegroups.com.
> To unsubscribe from this group, send email to

> nhusers+unsubscribe@googlegroups.com.