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
|
Here is my issue. Imagine a list of dogs, and a list of ShowEvents. Any one dog could be assigned to one or more showevents and each showevent could have one or more dogs assigned to it.
The entity framework is able to do this so the ShowEvent has a "Dogs" property and Dog has a "ShowEvents" property. How can I accomplish this in Lightspeed, or do I need to do that thru Stored Procs? |
|
|
See "Through Associations" in the help file. Basically the trick is to define DogShowEventMap as an entity with many-to-one associations to both Dog and ShowEvent, then put a ThroughAssociation link between Dog and ShowEvent with DogShowEventMap declared as the through entity. The ThroughAssociation is what provides the "Dogs" and "ShowEvents" properties: the DogShowEventMap handles the plumbing, and provides access to the HandlerName property for any given ShowEvent-Dog association. This is easily done in the designer by dragging a ThroughAssociation arrow from Dog to ShowEvent. Then select the arrow, go to the Properties window, and in the Through Entity box select DogShowEventMap. Note that, if you have control over the database, we would recommend that DogShowEventMap have its own Id column (rather than using a composite key) and that DogId and ShowEventId be normal columns with foreign keys. |
|
|
Here's a tutorial: http://www.mindscape.co.nz/blog/index.php/2009/09/17/many-to-many-associations-in-the-lightspeed-designer/
|
|
|
[quote user="ivan"]... we would recommend that DogShowEventMap have its own Id column (rather than using a composite key) and that DogId and ShowEventId be normal columns with foreign keys.[/quote] May I ask why you would recommend this? I want to enforce that a particular dog can only be assigned to a ShowEvent Once. If I make the key a composite of the two relationship keys that uniqueness property is inherient. I suppose that I could do it your recommended way and add a unique index to the table, but... why add that extra layer? Just curious as to the reason for the recommendation. Matthew |
|
|
Basically because it's easier in LightSpeed to work with entities where LightSpeed can control the ID. LightSpeed can't generate composite keys for you, so you need to dive down into the GeneratedId() stuff mentioned in the CK blog post you linked, and generate the key struct yourself. Whereas if you have a separate Id column, LightSpeed will just fill it in for you whenever it's needed and you don't need to think about it. I agree it's less natural at the database level, but paradoxically it turns out to be *more* natural at the object level -- which is what you'll actually be writing your code against. (Also, in the CK scenario, you need to do some additional mapping to get the associations to use the CK fields as foreign key fields; if you let the FK columns be normal columns, the additional mapping step isn't required. Finally, you'll lose some of the LightSpeed designer's database sync capability.) Hope this makes sense. To be clear, there's nothing wrong with the composite key design, and we do support this approach. It's just that we support the "single Id column" scenario better! |
|