Lazy ThroughAssociations

 It sure would be nice if a ThroughAssociation would lazy load the collection it is pointing to.

I was trying to Bind a ThroughAssociation to a ComboBox list and it kept coming up with Count = 0

when I visited the tables individually in a debug visualizer the data magically appears in the ThroughAssociation

A ThroughAssociation *should* load (lazily or eagerly depending on whether EagerLoadAttribute is present) the target collection.  For example, using the video sharing domain example from the help file, this works for us:

Tag tag = _unitOfWork.FindOne<Tag>(52);
Debug.Assert(tag.Contributions.Count == 2);

If you're seeing something different, can you provide us with any more information or a more detailed code sample so we can try to diagnose what might be going on?  Or have I misunderstood the problem?

Hi Guys,

 We're seeing the same/similar problems with our model. What I found from studying the documentation and the code generated by the Model designer is that they seem to be inconsistent.

The documentation shows that the intermediary (by lack of a better name) table needs to have both its EntityHolder fields set to [EagerLoad] for the ThroughAssociation to work properly, but the Model designer does not generate this kind of code. An additional property is that you can not separate the setting of the EagerLoad attributes on these field out to a partial class without ripping the whole thing out (and thus losing the designer support).

 Do you guys have plans to support ThroughAssociations in the Model designer or is there another way to properly implement this (without having to modify the generated class and loosing your changes when doing other changes in the model or having to 'manually' set up the through association in a partial class)?

Keep up the good work! Looking forward to LS 2.1!

Kind regards,

Robert 

We've been using ThroughAssociations in conjunction with the designer for a Web project we're working on, and you shouldn't need to "rip the whole thing out."

- You can set EagerLoad on the relationships through the designer using the Properties window.

- Then, in the partial class, define the ThroughAssociation in the normal way.

Here's an example from the Web project.  (This uses aggregates rather than straight EagerLoad but I'm sure it will give you the idea!)

.lsmodel file (X and Y are the related entities, and T the through-association class):

    <entity name="X" identityType="Int64" cached="true" cacheExpiry="5">
      <entityProperties>
        <entityProperty name="Name" />
      </entityProperties>
      <oneToManyAssociations>
        <oneToManyAssociation Id="a45a1816-0d7c-4fa1-9681-a065d3848861" collectionName="Ts" backreferenceName="X" isNullable="true">
          <entityMoniker name="//T" />
          <aggregates>
            <aggregate name="WithAllXData" />
          </aggregates>
        </oneToManyAssociation>
      </oneToManyAssociations>
    </entity>
    <entity name="Y" identityType="Int64" cacheExpiry="0">
      <entityProperties>
        <entityProperty name="Name" />
      </entityProperties>
      <oneToManyAssociations>
        <oneToManyAssociation Id="405d6d77-cbbf-4b01-afb5-fb5c0903d726" collectionName="Ts" backreferenceName="Y" isNullable="false">
          <entityMoniker name="//T" />
          <aggregates>
            <aggregate name="WithTs" />
            <aggregate name="WithAllYData" />
          </aggregates>
        </oneToManyAssociation>
      </oneToManyAssociations>
    </entity>
    <entity name="T" identityType="Int64" cacheExpiry="0" />

(All right, we admit it, our classes aren't really called X, Y and T, but you have to admit, it does give the system a kind of 1970s retro feel.)

Generated code (with some boilerplate removed):

  public partial class X : Entity<long>
  {
    private string _name;
    
    [EagerLoad(AggregateName="WithAllXData")]
    private readonly EntityCollection<T> _ts = new EntityCollection<T>();

    public EntityCollection<T> Ts
    {
      get { return Get(_ts); }
    }

    public string Name
    {
      get { return Get(ref _name); }
      set { Set(ref _name, value, "Name"); }
    }
  }

  public partial class Y : Entity<long>
  {
    private string _name;

    [EagerLoad(AggregateName="WithTs")]
    [EagerLoad(AggregateName="WithAllYData")]
    private readonly EntityCollection<T> _ts = new EntityCollection<T>();

    public EntityCollection<T> Ts
    {
      get { return Get(_ts); }
    }

    public string Name
    {
      get { return Get(ref _name); }
      set { Set(ref _name, value, "Name"); }
    }
  }

  public partial class T : Entity<long>
  {
    private long _yId;
    private System.Nullable<long> _xId;

    [ReverseAssociation("Ts")]
    private readonly EntityHolder<Y> _y = new EntityHolder<Y>();
    [ReverseAssociation("Ts")]
    private readonly EntityHolder<X> _x = new EntityHolder<X>();

    public Y Y
    {
      get { return Get(_y); }
      set { Set(_y, value); }
    }

    public X X
    {
      get { return Get(_x); }
      set { Set(_x, value); }
    }

    public long YId
    {
      get { return Get(ref _yId); }
      set { Set(ref _yId, value, "YId"); }
    }

    public System.Nullable<long> XId
    {
      get { return Get(ref _xId); }
      set { Set(ref _xId, value, "XId"); }
    }
  }

Now we put the through association from X to Y in a handwritten partial class file:

X.cs:

  public partial class X
  {
    private readonly ThroughAssociation<T, Y> _ys;

    public X()
    {
      _ys = new ThroughAssociation<T, Y>(_ts);
    }

    public ThroughAssociation<T, Y> Ys
    {
      get { return _ys; }
    }
  }

So at the moment the ThroughAssociation itself has to be handwritten in a partial class, but you should be able to model and generate all the supporting associations using the designer, and there should be no need to modify the generated code to enable the ThroughAssociation.  Let me know if you can't get it to work this way.

We have an item on the backlog to support ThroughAssociations directly in the designer, but this is unlikely to happen in time for 2.1 I'm afraid.

Hi Ivan,

 That's true, but it's it so that setting the property to EagerLoad in the designer sets the [EagerLoad] attribute on the 'end' table (ie. the EntityCollection) and not on the EntityHolder, as indicated in the documentation?

 It looks to me that this makes the relationship (as seen from the 'end' tables) EagerLoad, which, in your sample, is only circumvented, by specifying the AggregateName (which is actually a valid solution IMHO). Or am I misinterpreting/misunderstanding your point?

Would it be possible to have this added to the designer (the ThroughAssociation) or is this something that would be more trouble than it's worth?

 Regards,

Robert

I have checked with the guys who are working with some of this stuff at the moment and this is what I am told:

* The EntityCollection in the class that declares the ThroughAssociation (X in my example) needs to be eager-loaded.  (This can be done through an aggregate, but in that case you need to ensure that the aggregate is specified on the load if you intend to use the ThroughAssociation.)  If the through association is bidirectional -- i.e. there are ThroughAssociations declared at both ends (X and Y) then the EntityCollections at both ends need to be eager-loaded.

* The EntityHolders in the 'through association' class (T in my example) do *not* need to be eager-loaded.  They are shown as being eager-loaded in the sample code in the docs, but this is not a requirement.  I am assured that this is the case because we are doing exactly this in a current project!  (And this project is using the designer to model the associations.)  If you are seeing problems if the EntityHolders are not eager-loaded then let us know (if you could provide a repro case then that would be great).

It is certainly possible to have ThroughAssociations added to the designer but it is a matter of prioritising this versus other features I'm afraid... I will look into the effort involved and if it looks quick then we will see if we can slip it in!

Hi Ivan,

 That makes sense, but the problem I've seen with this in our system is that we have entities that have bi-directional through-associations to multiple tables. This, in one simple case, where I needed to retrieve only a few rows from one table, caused a large number of queries to kick off, causing the 'query' to take WAY longer than  it should.

I was actually retrieving one row by primary key from a table with only a few rows and, due to the added queries, ended up with a total query time of about 200 ms...

 While I can't show the exact example, the idea is that we have a couple of tables:

Table1 <-> IntermediateTable2 <-> Table3 <-> IntermediateTable4 <-> Table5

Querying Table1 will, through the Eager loaded Through Associations, also load data from Table3 and Table 5 (and obviously also IntermediateTable2 and IntermediateTable4).

 My solution of (manually) putting the EagerLoad attributes only on the EntityHolder fields in the intermediate classes instead, seems to work, although we haven't yet thoroughly tested this approach.

I hope this info helps you in making Lightspeed an even better system!

 Kind regards,

Robert

Hi Robert,

Any chance you can send through a small example model highlighting this? We would be keen to tighten up the way you declare and work with ThroughAssociations, so we would be keen to see what we can improve here. At the same time Ivan will be having a look at what sort of time is involved in adding this in to the designer so we can prioritize it accordingly..

You can either attach the code as a reply to this post, or email it through to support@mindscape.co.nz if that would be easier :)

Kind regards,

Jeremy

Hi Jeremy,

I'm trying to get a sample together, but of course it won't behave exactly the same as the 'real' thing... I'll get one to you, but don't hold your breath waiting for it

 Kind regards,

Robert

Hi Robert,

I have had a look at implementing designer support for ThroughAssociations and I don't think we're going to be able to fit it into the 2.1 timeframe.

Instead, as an interim step, I have added support for controlling eager load at the EntityHolder end of a one-to-many association.  This will be in the next nightly build (20080927).  The existing EagerLoad property has been renamed to Eager Load Collection, and there is now also an Eager Load Backreference property: set this to apply EagerLoadAttribute to the EntityHolder in the through-association class.  (You can also use named aggregates at both ends now too; existing named aggregates will continue to apply only to the EntityCollection end.)

This falls short of full TA support as you will still need to declare the ThroughAssociation field and property by hand in the partial class, but it will allow you to model all the one-to-many associations involved with the full load control you need.  I hope this is an acceptable compromise!

Please let me know if you run into any problems with the new designer support. 

Hi Ivan,

 Finally found some time to go through our model and do some cleanup. I pulled the last version from our account page, but after install I couldn't find the new properties you mentioned. Then  I noticed that the last nightly build is actually the one for the 26th of september...

 BTW, when I went through this thread again, I noticed that, before I asked about designer support for Through Associations, you actually already mentioned that you were working on it, but probably couldn't fit it in the 2.1 timeframe. My apologies for nagging about it. I didn't notice it before.

 How's the 2.1 release coming?

Kind regards,

Robert

Hi Ivan,

 Finally found some time to go through our model and do some cleanup. I pulled the last version from our account page, but after install I couldn't find the new properties you mentioned. Then  I noticed that the last nightly build is actually the one for the 26th of september...

 BTW, when I went through this thread again, I noticed that, before I asked about designer support for Through Associations, you actually already mentioned that you were working on it, but probably couldn't fit it in the 2.1 timeframe. My apologies for nagging about it. I didn't notice it before.

 How's the 2.1 release coming?

Kind regards,

Robert

Hi Robert,

We have been undergoing a server move recently and this has caused disruption to the release of nightly builds.  The servers are now in their new home and we are hoping to resume the normal release of nightlies either today or over the weekend.  We're sorry for any inconvenience caused by the holdup.