Hi, some ramblings and vague advice... :) As long as all your normal actions and views make use of $this->data then you can get away with exporting "what's on screen" by simply using parseExtensions and a csv-layout (as Brandead points out).
But since you mention "tens of thousands of results" I imagine you want to export all records from a model and not just the current items on screen. I would probably give AppModel a special method or a find type (depending on your preference on that issue). But (looking at your example line) there is no need to pass the instance of "Product" to the method since you are running it on that instance already. Checking the schema of the model instance will enable your export to adapt to any of your models. I have added a "hidden_fields" attribute to my models at one time to make sure I can choose to not export some fields like created if that has no relevance. Your biggest problem is the possible processing time and memory usage for those >10'000 records. You can try to just tell php to not time out but that might not be enough or allowed or even desirable. Ways I would consider to get around it: Cache the csv file and only process the very latest records "on request". A nightly cron, during low traffic, could keep the csv updated. This would only work for WORM-type records and not continually changing (editable) data. Another problem is to get an efficient way to determine which records were cached. The modified time of the csv file might be enough. Keep a background task on the server that does the actual processing and let the web-interface keep polling for it to be completed. This would be similar to how bleep.com create a zip-archive of music you purchase before you download. I have slightly similar tasks that take (thousands of) transactions and process them into statistically friendly data in another table. Since there are literally millions of rows I run this from a shell to avoid timeouts. I also "page" the query to around 1000 records at a time in a loop to avoid memory problems. Since I store the results in another table I can keep the id of the original record in the statistical table so that I do not create duplicate entries. This also enables me to fix calculation errors and re-process all the data is necessary since I can update the existing records with new figures. /Martin On Apr 15, 5:49 pm, Chez17 <che...@gmail.com> wrote: > Hello all, > > I have a client that wants to be able to export any results he sees on > screen to a csv file. This will be used for different models and will > need to work on large queries. I was wondering if anyone would be > willing to share their thoughts on the best 'cake' way to do this. I'm > asking for high level, no code, thoughts. Here is sort of what I am > brainstorming. If I modify app_model to have an exporter function that > takes an model instance and a conditions array that might make a lot > of sense, so I could do things like this: > > $this->Product->csvExporter($this->Product, $conditions); > > This would work for multiple models. Would a component make more > sense? The issue this brings up is that how do I pass the information > to get the conditions? Some of these queries will be returning tens of > thousands of results. I was thinking of having a link on all the pages > like "Export this to csv" and it would open a new window so if it took > some time, the user could do other things. So I have to get the > current conditions to the new window somehow. > > Any thoughts on this would be most appreciated. Thanks. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
