IowaDave wrote:
Thanks, I thought I could do it through one FetchEntity call, but that's ok....
however....
I think I see the problem here. Because product to colors is a 1 to 1 relationship,
Colors is a ColorsEntity and not an EntityCollection so I can't do a FetchEntityCollection(pe.Colors).
It's an m:1 relation
That makes sense. If you have an FK from product to colors, there can be just 1 color associated with a product entity, so if you load a product entity, you get just 1 color entity as well, namely the one associated with the product entity.
This is a slight problem in that our client views are wanting the collections that
support editing an entity. We are trying to build a very chunky access layer in that
the data needed are all contained in the entity class.
Couldn't you make Colors a collection and even if it's a one to one, then it would
have just one element, but one could fill up the collection with, for example, all available
selections. That would satisfy our desire to use the entity class to pass all the data back to the client. Cool, huh? or maybe not. I realize it makes sense for a 1:1 to be a single entity but I also think the collection class would be more versatile. Or am I trying to bend your creation to my warped way of doing things?
hehe
Well, making it a collection would not be logical. What I think would make more sense, is that you create a separate object which contains the collections for the editor. This way, you just fetch one time the colors collection, even though you have 10 products loaded