One-way associations

Hi!

I`ve got entity A and entity B. And I need to have "one-way" one-to-many association between them. It means entity B should have a reference property to A, but entity A shouldn`t have a collection of entities B.

I can do it in the designer by set Collection Name of the association to empty. Also I can do it in code by add attribute NoReverseAssociation to reference proterty of entity B.
But it requires entity A to be cached.

My first question is: why does entity A have to be cached?
And my second question is: is there any way to mark many-to-many association as "one-way"?

Thanks! And sorry for my English )

The reason it requires Entity A to be cached is that there is a performance impact if it isn't.  For internal reasons, not having the EntityCollection results in redundant lookups.  Because the original use case for one-way association was reference data, which would be cached, we did not attempt to eliminate the redundant lookups -- we just added an alert if you did a one-way association to non-cached data.  If you have a requirement for a one-way association to transactional data, we can look at removing this restriction, but we'd like to understand the use case before we invest effort in it.

There's no way to mark many-to-many associations as one-way.  Sorry!

I'd like an option for one-way associations to not be cached (with good performance and no designer warnings).

Here is my use case:

I am using concrete table inheritance and on the base entity there is a CreatedByUser association to a User entity. This works if the association is one way and I'm happy with this but I don't want User entities cached because they're a typical mutable User entity.

Further sometimes when getting the base entity a named aggregate will be used to eager load the CreatedByUser and further associations off the user (although none that involve inheritance).

In recent nightlies, if you initialise the EntityCollection to null instead of new EntityCollection<...>() then LightSpeed will not try to populate the collection (since there isn't a collection). This effectively produces a one-way association which I believe would avoid redundant queries even though the target entity type is not cached. I have not carried out performance testing on this, so you should measure it before applying it widely or using it in production.

Remarks:

• The formal EntityCollection field is still required even though it is always null.
• You should obviously not provide a public wrapper property for the always-null EntityCollection.
• The designer doesn't have an option for this, so you will need to do it by hand in the partial class. If the measured performance is satisfactory for you then we can consider implementing designer support.
• Yes, it is muddled to have two ways of doing this; we will try to consolidate them in a future release but compatibility constraints mean we won't be able to do this for 4.x.

Why could performance be poor?

Just to check, when using a one way association in my example above I don't want CreatedByUser to be cached but I also don't want it reloaded from the database every time I access the CreatedByUser property on the base entity.

CreatedByUser would be cached in the identity map, like entities always are. It would not be cached in the L2 cache unless you marked the User type as cached.

That's good. Why are you worried about performance? What should I do to check it?

I'm not particularly worried about performance, but as noted upthread, the NoReverseAssociationAttribute implementation of one-way associations can result in a large number of redundant queries (which is why we insist on caching). I don't believe this is an issue with the null collection approach, but I haven't actually tested it, so I thought I ought to warn you! grin

Can you give an example of a couple of entities with one-way association without caching? The instructions here plus what you've described plus the fact that I only use the designer and don't define relationships in code means I'm at a loss of where to begin. This stuff seems very off the beaten path and if (when) I run into problems I don't want to waste time not knowing whether I'm defining it wrong or whether there is a bug in LightSpeed that means it is currently not possible.

Also once I have a one-way non-cached association running and I do happen to encounter many unnecessarily queries, is that a bug that I should report to be fixed?

Here you go:

public class CollSkipComment : Entity<int>
{
  private int _contributionId;

  public int ContributionId
  {
    get { return _contributionId; }
    set { Set(ref _contributionId, value, "ContributionId"); }
  }

  private readonly EntityHolder<CollSkipContribution> _contribution = new EntityHolder<CollSkipContribution>();

  public CollSkipContribution Contribution
  {
    get { return Get(_contribution); }
    set { Set(_contribution, value); }
  }
}

public class CollSkipContribution : Entity<int>
{
  private readonly EntityCollection<CollSkipComment> _comments = null;
}

If you see unnecessary queries, please let us know.

I get this error after adding the association in code:

Mindscape.LightSpeed.LightSpeedException : Descendent type [Blc.Common.Model.Entities.BlogPost] of type [Blc.Common.Model.Entities.ThingBase] is not discriminated

I am using concrete table inheritance and ThingBase is the base class and BlogPost is an entity that inherits from it. The association is one way from ThingBase. My first post has more information about what I'm doing.

Can you post a repro please? Thanks!

Sorry I don't have the solution handy right now. My scenario is like your code example except CollSkipContribution is abstract and has a bunch of concrete table implementations.

If you can't replicate the error then I'll email the solution file + partial class to you tonight.

Edit: Actually I might have the abstract class back to front. I'll double check tonight and email you the model.

I was right, the difference in what I'm doing compared to your example is CollSkipContribution is abstract.

I've emailed you a copy of my model + pertinent partial classes.

The difference is that you're trying to use polymorphism with concrete table inheritance:

public partial class ThingBase
{
  private readonly EntityHolder<Thing> _thingReference = new EntityHolder<Thing>();
}

// No discriminator
public partial class Thing { }

Concrete table inheritance does not support polymorphism. You cannot have a polymorphic association to a concrete table inheritance base class, only a leaf class.

http://www.mindscapehq.com/documentation/lightspeed/Domain-Modelling-Techniques/Inheritance

Thing doesn't have anything inheriting from it, ThingBase does, that is why I'm adding a one way association from the ThingBase class to Thing (I know the names are slightly confusing, I'm going to rename Thing to ThingReference once this is working).

Basically I'm trying to do exactly what was added here - http://www.mindscapehq.com/forums/thread/4808 (your 4th post) - but without the caching.

It's still basically the same issue - LightSpeed is worried about the reverse association, EntityCollection<ThingBase>, needing to be polymorphic even though it is never initialised.

Unfortunately, in the current architecture there's no way for us detect that an association wil never be used (and we can therefore ignore the polymorphism problem), so I've had to provide a way for you to tell us. This will be in the next nightly build. You will need to apply the new NullAssociationAttribute to the entity collection field.

I also found that because you have multiple associations from Thing to within the ThingBase hierarchy, you will need to explicitly specify the reverse associations on the ThingBase._things and Thing._thingReference association fields (using the ReverseAssociationAttribute).

No problem adding more attributes, as long as it works :)

Is how the new attributes should be used?

  public partial class Thing : IThing
  {
    [Transient]
    private Guid? _id;

    [NullAssociationAttribute]
    [ReverseAssociationAttribute("ThingReference")]
    private readonly EntityCollection<ThingBase> _things = null;

    public void SetId(Guid id)
    {
      _id = id;
    }

    protected override object GeneratedId()
    {
      if (_id == null)
        throw new Exception("Id not set.");

      return _id.Value;
    }
  }

  public partial class ThingBase : IThing
  {
    [Transient]
    private Guid? _id;

    private Guid _thingReferenceId;

    public Guid ThingReferenceId
    {
      get { return _thingReferenceId; }
      set { Set(ref _thingReferenceId, value, "ThingReferenceId"); }
    }

    [ReverseAssociationAttribute("Things")]
    private readonly EntityHolder<Thing> _thingReference = new EntityHolder<Thing>();

    public Thing ThingReference
    {
      get { return Get(_thingReference); }
      set { Set(_thingReference, value); }
    }

    public void SetId(Guid id)
    {
      _id = id;
    }

    protected override object GeneratedId()
    {
      if (_id == null)
        throw new Exception("Id not set.");

      return _id.Value;
    }
  }

Well, it Works On My Machine (TM). Your inheritance hierarchy is quite complex so it's possible there may be issues I didn't pick up in my tests depending on where you enter the hierarchy -- if so, drop us a repro and we'll sort it out.

Your usage example is correct.

I am getting many errors:

UnitOfWork.Query<User>().SingleOrDefault(o => o.Id == id);

System.NullReferenceException : Object reference not set to an instance of an object.
    at ..
( )
    at ..ƒ( )
    at Mindscape.LightSpeed.Sql.SelectStatement.ƒ( )
    at ..ƒ( )
    at ..ƒ(IEnumerable`1 )
    at ...ctor(IUnitOfWork , IEnumerable`1 )
    at Mindscape.LightSpeed.Data.DataProviderAdapter.
(IUnitOfWork , IEnumerable`1 , ProviderOptions )
    at ..ƒ(TypeModel , Query , IList )
    at ..ƒ(Query , TypeModel , IList )
    at ..ƒ(Query , IList )
    at Mindscape.LightSpeed.UnitOfWork.Find(Query query, IList results)
    at Mindscape.LightSpeed.UnitOfWorkBase.Find(Query query)
    at Mindscape.LightSpeed.Linq.Plan.SingleQueryPlan.ExecuteImmediate(IUnitOfWork unitOfWork, Type returnType)
    at Mindscape.LightSpeed.Linq.LinqQueryProvider.Execute(Expression expression)
    at Mindscape.LightSpeed.Linq.LinqQueryProvider.System.Linq.IQueryProvider.Execute[S](Expression expression)
    at System.Linq.Queryable.SingleOrDefault[TSource](IQueryable`1 source, Expression`1 predicate)

And a more complicated query:

var friends = (from f in UnitOfWork.Users
               join fr in UnitOfWork.ThingRelationships on f.Id equals fr.ToThingId
               join rr in UnitOfWork.ThingRelationships on f.Id equals rr.FromThingId
               where rr.ToThingId == thingId && rr.ThingRelationshipTypeId == relationshipTypeId
                && fr.FromThingId == userId && fr.ThingRelationshipTypeId == ThingRelationshipType.FriendId
               select f).ToList();

Mindscape.LightSpeed.LightSpeedException : Cannot find field Id for join
    at Mindscape.LightSpeed.Querying.Selectable.TypeSelectable.ƒ(IUnitOfWork , String , String )
    at Mindscape.LightSpeed.Querying.Join.ƒ(IUnitOfWork , EntityMap )
    at ..ƒ(AliasedTypeModel )
    at ..ƒ(LightSpeedContext , List`1 , QueryExpression , Order , Group , String , Boolean , Boolean )
    at ..ƒ(List`1 , Query , String , IdentifierExpression )
    at ..ƒ(List`1 , Query , EntityTuple )
    at ..ƒ(Query , EntityTuple )
    at Mindscape.LightSpeed.UnitOfWork.FindGroup(Query query, EntityTuple results)
    at Mindscape.LightSpeed.UnitOfWorkBase.Find(Query query, EntityMap typeMap)
    at Mindscape.LightSpeed.Linq.Plan.SingleQueryPlan.ExecuteImmediate(IUnitOfWork unitOfWork, Type returnType)
    at Mindscape.LightSpeed.Linq.LinqQueryProvider.Execute(Expression expression)
    at Mindscape.LightSpeed.Linq.LinqQueryProvider.System.Linq.IQueryProvider.Execute(Expression expression)
    at Mindscape.LightSpeed.Linq.LinqQuery`1.GetEnumerator()
    at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
    at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)

And when I set the ThingReference property:

System.NullReferenceException : Object reference not set to an instance of an object.
    at Mindscape.LightSpeed.Entity.SetInternal(IEntityHolder , Entity )
    at Mindscape.LightSpeed.Entity.Set[TEntity](EntityHolder`1 entityHolder, TEntity value)

Hmm, I'm looking into a patch for this, but there seems to be an issue with a circular association:

User.ThingReference (of type Thing) (inherited from ThingBase)
Thing.CreatedByUser (of type User)

The bug you've identified stopped us detecting this problem, but it looks like fixing that bug is just going to cause LightSpeed to reject the model on the grounds of circular association, so I can't verify the fix. I think you'll need to address the circular reference before we can progress this for you -- sorry!

I was planning on moving that CreatedByUser association to ThingBase and making it one way as well once they were working. You can delete it from Thing.

Okay, I haven't been able to reproduce your exact errors, but I've implemented fixes for a couple of problems that I found when running your repro cases, and they now appear to run correctly. I'm still a bit concerned, though, that I didn't see the exact same thing as you, so if you still see problems after the next nightly build, put together a minimal repro and let me know. Thanks!

I've mailed you about a new error I'm getting. As far as I can tell I'm still using setting up the relationship and using the attributes like I asked about but I could have broken something. I'm having to add and remove the relationship while I work around it.

Looks like we still had an issue wiring up associations in concrete table inheritance base classes. There'll be a fix in the next nightly build.

My unit tests now pass. I found a bug when eager loading is enabled however:

WHERE
  EXISTS (
    SELECT
      [User].*
    FROM
      [ThingBase] [User]
    WHERE
      [User].[ThingReferenceId] = [Thing].[Id] AND
      [User].[Id] = @p0
  )

This is generated when getting a User entity. It is using the base class in the FROM rather than just User.

Thanks. There's a candidate fix on its way in the next nightly build. (There may still be an issue with longer eager load chains -- let us know if you run into this.)

I've run into it:

FROM
  [ThingDataSource]
WHERE
  EXISTS (
    SELECT
      [Thing].*
    FROM
      [Thing]
    WHERE
      [Thing].[Id] = [ThingDataSource].[ThingId] AND
      EXISTS (
        SELECT
          [Place].*
        FROM
          [ThingBase] [Place]
        WHERE
          [Place].[ThingReferenceId] = [Thing].[Id] AND
          [Place].[Id] = @p0
      )
  )

Fixed in the next nightly build.