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
|
I need to represent aggregate type, ie, multiple one-to-one associations. Please refer the attached picture. In the picture, Inventory has both PrimaryGun and SecondaryGun, each represented by one-to-one association In this case, Gun will have two "Inventory". Saving the Model won't error but it will generate compile error having duplicated "Inventory" Is there way to present the above relationship? Thanks. -chris |
|
|
Your picture didn't come through for some reason, but going by your description, I think all you need to do is rename one or both of the Inventory associations (e.g. PrimaryInventory and SecondaryInventory). We'll try to add a validation check for this. |
|
|
Opps, Sorry, Here is the picture again. Thanks. |
|
|
Thanks. Renaming one or both of the Inventory associations should do the trick. |
|
|
Hi, Ivan, Right, I know that would be easy and I wouldn't have asked. ^^ However Gun belongs to only one Inventory and it doesn't make sense to have PrimaryInventory and SecondaryInventory. (Gun doesn't know or need to know which inventory it came from) It's more like one-to-many association, with each member of collection being keyed on names, kind of like Dictionary instead of List. I would probably just rename Inventory but it's a pretty common situation and have many other cases like this. I wanted to find out if there is a better way to deal with it. Thanks. -chris |
|
|
There's no built-in way to deal with this situation. One suggestion (and it is only a suggestion!) would be to use a one-to-many association but set its Generation to FieldOnly (or its visibility to Private). Then instead of surfacing the Guns collection directly, provide wrapper methods or properties to perform a lookup in the collection, and mutator methods to update the collection. Your mutator methods can figure out whether they need to add the Gun to the collection or replace an existing Gun, and can validate that there are no more than two Guns in the collection, etc. The tricky bit might be the keying -- this will work fine if the key is an attribute of the Gun but could be problematic if the key is an attribute of the association. And of course if you have other situations like this then you'd need to repeat the same technique for those other situations. Alternatively you could keep the one-to-one approach, make the one-to-one associations FieldOnly, and just not surface the two XxxInventory fields -- leave them as private fields which are never accessed. |
|
|
Hi, Ivan. Thanks for your suggestions. I didn't expect Lightspeed can handle all situations. However, LightSpeed handles one-to-many already, I thought adding Dictionary support wouldn't be too difficult.. If Dictionary can be added somehow, it might be a very powerful extention. Anyway, I need to think little more but it give me enough information. Thanks a lot! -chris |
|