This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
can self referencing many to many relationships be modelled in lightspeed? regards daren note: using 3.0 beta
|
|
|
tried creating the tables i was after in the db and then doing an update from source and got the 2 one to many associations i was trying to do in the first place via the designer, not sure what i did wrong.
|
|
|
This works in the runtime, but is not fully supported in the designer. The problem is that the designer doesn't provide a way to map which end of the through association corresponds to which one-to-many association from the self-referencing entity to the through entity. (A ThroughAssociation object always wraps a one-to-many association, and a through arrow results in two ThroughAssociation objects, one for each end of the arrow.) So you can model the two one-to-many associations in the designer, but if you try to add the through association from the self-referencing entity to itself, you will get a validation error "Multiple or no one-to-many associations from Person to through entity on through association from Person to Person." You would therefore need to model the through association in code via a partial class. I can provide a code sample for this if it would be useful. You won't be losing anything by this except a bit of visibility -- TAs are not represented in the database, so designer sync will still work fine. I've logged a bug for this -- thanks for drawing our attention to it. |
|
|
hi ivan
yes a code sample would be great
thanks daren |
|
|
Here's what you need. In this case the self-referencing class is called Person, the through entity is called PersonPerson, and the collection name of the one-to-many association to the through entity is PersonFriends1: private ThroughAssociation<PersonPerson, Person> _friends1; You would typically have another occurrence of the same pattern for the reverse direction (which is why I have used the suffix 1, though hopefully you can find more meaningful names than Xxx1 and Xxx2!). However, LightSpeed doesn't require you to do this -- if the many-to-many can only meaningfully be traversed in one direction then you don't need to create a ThroughAssociation for the other direction. Hope this is clear -- let me know if you need any more info. |
|
|
ok thanks, i will give that a go |
|
|
ivan, i've been scratching my head with the finding "meaningful names" bit. i thought i had it working at one point but it seemed whatever i did something seemed to be meaning the opposite :) i'm diving in to the 3.0 beta with only a little experience of 2.x and I keep crashing VS and wiping out my Model.cs so i think i need a better grasp of what the ThroughAssociation is giving me and decide if I can do without it. correct me if i'm wrong but it would seem that it is only useful in low cardinality situations. eg. for the ContributionTag scenario it makes sense in the direction in your demo because you load all the tags but not for the other direction Tag.Contributions where there could be millions of contributions the scenario i'm trying to model is a bit difficult to explain but for simplicity take these 2 examples Do I have it about correct? Thanks Daren
|
|
|
Yes, I think that's fair comment. The way LightSpeed works is to materialise objects in memory. If you're dealing with millions of items, the memory load of materialising an object for each one may become unacceptable. The memory load is reduced somewhat by not loading associations until you ask for them: but once you ask for an association (Daughters or Followers), we do load the whole lot, and that will have scaling issues when "the whole lot" is millions (assuming the entities are non-trivial). This isn't specifically a self-referencing issue, by the way: this would affect any collection / association with millions of items in it. Now I'm guessing you probably don't need to have all these millions of items in memory at once: rather, you're probably looking at maybe counting ("Bob has 12934892 followers"), searching ("Find me all Bob's followers named 'Alice'") and paging ("Get me Bob's 401st-500th followers in order of name"). Through associations won't do this for you, but you can do it manually using the through entity collection. E.g. var followers = (from pp in uow.PersonPeople (The query may not be exactly right but you get the idea.) It's obviously more laborious than just using a ThroughAssociation but it gives you the finer control you need over what gets loaded. Note you can use eager loading on the PersonPerson.Follower association to have the join entities and the followers loaded in a single database hit so as to avoid an N+1 problem. In summary, ThroughAssociation is a convenience helper for the many-to-many scenario. You're not required to use it: you can always "do without it" by dropping down to working directly with the join entities and their associations to the business entities. Hope this helps -- happy to provide further info if required. |
|