not-null property references a null or transient value while testing bi-directional mapping

[Thestrup]

Having found and followed the solution in this thread
http://groups.google.com/group/fluent-nhibernate/browse_thread/thread/cebc70ff873e4fd2/ce6cc622bc02d9c
I still come up empty handed while trying to solve the following
problem:

I have a bi-directional one-to-many relationship between two entities,
Match and Goal. I have the following domain objects:

public class Match
{
public virtual int Id { get; private set; }
public virtual IList<Goal> Goals { get; set; }

public virtual void AddGoal(Goal goal)
{
goal.Match = this;
Goals.Add(goal);
}
}

public class Goal
{
public virtual int Id { get; private set; }
public virtual Match Match { get; set; }
}

The Goal can have only one Match, and a Match can have multiple Goals.
This is the mappings:

public MatchMap()
{
Id(x => x.Id);
HasMany(x => x.Goals)
.Inverse()
.Cascade.All()
.AsSet();
}

public GoalMap()
{
Id(x => x.Id);
References(x => x.Match).Not.Nullable();
}

When I perform this test I get a “not-null property references a null
or transient value Goal.Match”
var goals = new List<Goal> { new Goal() };

new PersistenceSpecification<Match>(Session, new
CustomEqualityComparer())
.CheckProperty(c => c.Id, 1)
.CheckList(c => c.Goals, goals, (match, goal) =>
match.AddGoal(goal))
.VerifyTheMappings();

At first I didn’t have the AsSet() on my MatchMap, but having read
this: http://www.nhforge.org/doc/nh/en/index.html#collections-bidirectional,
it seems that it is required to use either bag or set and not list.

If I remove the Not.Nullable on the reference to Match in GoalMap the
test works, but I want to have that constraint, since it doesn’t make
sense to have a Goal without it being tied to a Match.

Is there anybody out there, who can help me solve this problem (which
I’m sure is pretty trivial once I reach enlightment ….)

[Michael Powell]

In my experience with this type thing, take a look at what objects are persisted or not persisted. It sounds like you are trying to persist the goal, which is plausibly transient (?) while the match has already been persisted (?). I would persist the match with a newly added goal and see what you find...

> Date: Sat, 14 May 2011 09:29:39 -0700
> Subject: [fluent-nhib] not-null property references a null or transient value while testing bi-directional mapping
> From: sorent...@gmail.com
> To: fluent-n...@googlegroups.com

> --
> You received this message because you are subscribed to the Google Groups "Fluent NHibernate" group.
> To post to this group, send email to fluent-n...@googlegroups.com.
> To unsubscribe from this group, send email to fluent-nhibern...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/fluent-nhibernate?hl=en.
>

[James Gregory]

+1 to what Michael said.

Which entity are you trying to persist? Your goals collection is set to cascade, so if you were saving a Match it should cascade the save to Goal, but your References in Goal isn't set to cascade so it wouldn't work the other direction.

[Thestrup]

I'm totally new to Fluent NHibernate, so chances are that I'm doing
something wrong :-)
At this moment I'm only testing my match mapping using the
PersistenceSpecification, so when you're asking what I'm trying to
persist, my first thought is nothing?

Michael mentions persisting a match with a newly added goal to it, and
I actually thought that this was exactly what the test was trying to
do? (again pointing out my newbines :-)

I tried adding cascading to the reference in Goal, but that didn't
help. I also tried removing Inverse from Match Mapping, but that
didn't have any effect either (and I'm still not quite if I'm using
Inverse correct)

I might be trying to test something that isn't supposed to be tested?
Maybe I only need to test the relationship from the many end?

[James Gregory]

Ah, I completely missed that you were using the PersistenceSpecification! My bad.

What happens if you don't try to assert on the goals collection? (ie. just check the Id). Does that work?

What happens if you create a PersistenceSpecification<Goal> and do it the other way around?

I'm guessing there's probably some kind of issue in the PersistenceSpecification, as there doesn't seem to be anything immediately obvious about your mappings.

[Thestrup]

> What happens if you don't try to assert on the goals collection? (ie. just
> check the Id). Does that work?

Yes, that works.

> What happens if you create a PersistenceSpecification<Goal> and do it the
> other way around?

This also works.

> I'm guessing there's probably some kind of issue in the
> PersistenceSpecification, as there doesn't seem to be anything immediately
> obvious about your mappings.

After having search some more on the web, it seems as if there might
be an unsolved issue with CheckList.

Would it be sufficient to test only one side of a relation (like
testing only Goal to Match and not the other way around) or do I need
to make a more "manual" test to ensure that my mapping is correct?
(Save, flush, read). It might even be considered wrong to test the
Inverse side?