I have the following 3 tables:

Event
id (PK)
plan_id (FK to Plan)

Plan
id (PK)
name

PlanDetails
 id (PK)
 plan_id (FK to Plans)
 some_info

I want to query an event by ID and expand the plan and PlanDetails associated with the event. But only the first of the PlanDetail records gets loaded.

The query that is produced is correct and returns 2 records because there are 2 details. But resulting object has only one detail populated inside Plan's __objPlanDetailsAsPlanArray.

I have tried removing the QQ::Expand(QQN::Event->Plan) clause and that has no effect.

(I am using QueryArray because QuerySingle populates __objPlanDetailsAsPlan. I saw this is a known bug that has a patch for it. But this does not seem to be related.)

When i query Plan directly and ExpandAsArray  on PlanDetailsAsPlan  this works correctly and i get 2 PlanDetails.

QCodo 0.4.10

THanks for the posts...

I've added the support so that QuerySingle now does ExpandAsArray.

However, taking a look at the code you suggested from QCubed for a ExpandAsArray support on a linked object... if I'm seeing the code correctly (which I've been known to do incorrectly, so please do correct me if I am wrong =) this will cause quite a bit of performance lag as it's now needing to keep track and compare against the entire result set to check on expansions EVERY time.  Especially as your data sets get larger, this will become, in essence, an N-squared algorithm, which is not ideal.

I thought about the idea of only having it perform the analysis if it knows for sure that there is ExpandAsArray going on (e.g. putting the entire check around an if() statement) -- however, that means that any time you do an ExpandAsArray, even the simple case one, you end up with an N-squared algorithm to perform the expansion.  That performance lag specifically counteracts the optimization you would normally be doing with ExpandAsArray in the first place.

I checked and I can't find it in my personal notes, but if memory serves, I believe I went with the current approach of ExpandAsArray specifically because of this issue.  In short, it may be very very difficult to correctly perform a nested ExpandAsArray as the original poster is requesting in a way that doesn't take a performance hit.  The bottom line is that to do ExpandAsArray efficiently, you really must limit the analysis to the row immediately preceding the current row -- but to do ExpandAsArray in a nested fashion, you'll need to send back the entire resultset every time you examine a row... which is the source of the performance issue.

I'm going to go ahead and specify this bug as fixed (since we've gone ahead and fixed the QuerySingle issue)... but if you want to discuss further, please feel free to post here.

Mike Ho made edits to the issue, including:

• Status changed from Fixed to Closed
• Resolution changed from none to Won't Fix