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
|
Hello - I'm not sure if this has been addressed here before. but I did a search and turned up nothing. Feel free to refer me to another thread if you have answered this already somewhere else. I want to have a table, call it Atrributes, that holds general info about properties for the parent entities, thus: CREATE TABLE [dbo].[Attributes]( The question is, what is the best way to create the relationships so LightSpeed handles them with the least work and fuss? I can see at least 3 different methods to do this: 1) Add a separate Foreign Key field for each table that uses the list, so you would add fields something like Parent1ID, Parent2ID, etc and create explicit relationships for each. Set the default for each foreign key field to 0. 2) Add 2 fields, one called ParentEntityID and the other called ParentEntityType, create relkationships using ParentEntityID as the foreign key to all parent entities, and assign a meaning to the type field such that a type of 1 would map the ParentEntityID to Parent1, etc. I'm thinking LightSpeed would have problems with this approach, but I have used it in the past with some success. 3) Create multiple almost identical tables, where Parent1Attributes would have a foreign key to Parent1, Parent2Attributes would have a foriegn key to Parent2, etc. This is the simplest, but certainly not the most elegant, of the solutions. I know how to do any of the above using standard ADO.NET and datatable/dataset stuff, but I don't want to go to all that work. That's why we purchased LightSpeed, right? Please let me know which method LightSpeed supports most natively, and I will go that direction. This is a new database design, and I have 2 or 3 places where this kind of structure is needed, so I have the luxury of choosing whatever works the best.
Thanks, Dave |
|
|
Hi Dave, In general the better way to model it would be to use a soft approach (option 2 above), but it will depend somewhat on your actual implementation and requirements. The downside with this approach from a LightSpeed perspective if you will need some custom application code to handle loading in the associated entity. You could however easily set this up via a custom property which you implement on a partial for your Attribute class, e.g. public T GetParent<T> where T : Entity { get { return UnitOfWork.FindById<T>(ParentEntityId); } } Or you could also look at implementing a specific interface if your parent interactions would form a contract and you are less interested in the specific type of the parent. Since that was a fairly generalised response, feel free to fire back any questions if you want to talk through this some more.
Jeremy |
|
|
Jeremy - Thanks for the response. You're right, I will need to get to specifics before I ask any more questions, but I'm with you in that the second approach is the better one in general. Here's one situation - say I want to retrieve the parent and all associated child records. How should I get the child records once I have the parent? I could probably hack something together where I first get the parent's ID value, then write a query that returned all child records for that parent, ie where ParentEntityID == parent ID and ParentEntityType == 1, or 2 or whatever is appropriate, but I'm hoping for a more elegant solution. Can you give me a quick example showing how that would work? If there is code in the samples that shows that, can you help me locate it? Thanks, Dave
|
|
|
I think you may want to look at using an conditional eager load of the child collection to solve this problem. LightSpeed has a feature known as named aggregates which lets you conditionally eager load child collections based on a name which you indicate as part of the query. There is a blog post by Ivan which describes this in a reasonable level of depth here: http://www.mindscape.co.nz/blog/index.php/2008/06/30/controlling-eager-and-lazy-loading-in-lightspeed-models/ if you want to have a read through that to familiarise yourself with how it works. I am thinking from what you have described, you could apply a named aggregate for loading in the children with the parent and then filter based on ParentEntityType client side using LINQ. e.g. You have a named aggregate of WithChildren set up on the association then your GetParent property could look something like this: public T GetParent<T> where T : Entity { get { Query query = new Query() { Identifier = ParentEntityId, Aggregate = "WithChildren" }; return UnitOfWork.FindOne<T>(query); } }
Jeremy |
|