I'm guessing this quandary explains why most "easy" database manipulation packages (say, FileMaker and Omnis) usually limit the automatically-fetched associated records to one level deep. More generally, I find that recursive fetching has a tendency to bring in much more than I need. I have to go fishing around in the arrays to find the things I actually want, simultaneously noticing how much data that is fetched is not used.
I guess in effect what we're groping for here is like query optimization, but at the application level. In effect cake is sitting between the view's data specification and the database server. The ideal cure would be for cake to generate queries based on what fields at each level are actually used in the view. That would mean deferring the queries until view requests have been accumulated. I believe that would be very different from the present method. The next best answer might be to have the application programmer specify, at the controller level, some sort of outline as to what data is going to be used. This latter method, if feasible, would eliminate the simplistic specification of levels of recursion. If it were optional that might preserve the easy part of cake data fetching, while making more detailed specification possible. (My apologies if what I've written here does not correctly address the topic at hand.) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php -~----------~----~----~----~------~----~------~--~---
