Your PricePair has no identity, which can cause exactly the behavior you describe. If the data has a surrogate primary key, that's best. Otherwise, as long as the price and mw combination is globally unique, you can set them both to id elements, like this:
If you don't a surrogate primary key, and price/mw pairs are allowed duplicates in certain cases, then try joining against a sub-select (virtual/dynamic table) that includes a row number that you can use as the primary key.
Finally, if all else fails, you may consider using a sub-select -- this will introduce the N+1 selects problem, but that will only be of concern if: 1) there are hundreds or thousands of rows, 2) if the parameters used to look this up (in this case mkthour I guess) are always different. The session cache will catch N+1 in a single session.
Try a few of those out to see if you can figure something out, and let us know.
This post has NOT been accepted by the mailing list yet.
Thanks, that is helpful and I was able to create an id for the PricePairs that renders the result I expect.
However, I am confused, because the behavior seems inconsistent. How is it that the HourlyBids get contained in their expected parent Bid, even though the mkthour id is not globally unique? In fact, we had not declared any ids in earlier versions and all of our single-level collections rendered the way we
expected. We never saw an issue until we implemented these deeper two-level collections.
Looking at the result set, it seems there is sufficient information to determine how to build the object structure, regardless of ids. If a price and mw appear in a row, then they must be contained only within
a parent object that has been rendered from the same row. We should know what HourlyBid object
represents some subset of rows, so I intuitively expect that the PricePairs for that same subset of rows
belongs to that HourlyBid.