Thanks, deefens. I didn't think I was totally crazy about the view idea. :)
I did some research on the mysql pages, and you _can_ write to mysql views. I also did some research here, and it appears that views aren't officially supported in Cake, and some folks claimed they didn't work, period. That doesn't mean they don't work, though - I did some testing, and simple reads/writes actually work just fine. The constraint seems to be that the view is a single table view (no aliasing) - which is fine for my purposes. For some reason, though, that approach still worries me, and I can't put my finger on it. So, on the code approach angle, I followed up on Nate's idea, and I don't think I'm going to go that low level. For one, I'd like to stay away from DB specific approach, and for two, I'd have to do something funky to catch the model so I can fetch all the associations properly. And besides, after digging around some more in the model and schema class code, the existing methods do such a fantastic job of prepping and organizing the data before and after database access, it seems such a shame to waste all that work. :) So instead, I wrote a few custom methods: __getColumnPrefixData() - which reads the model and its associations and builds a small table of the models, aliases, and prefixes. __columnPrefixer() - which takes the data input and makes sure its formatted for the engine, and then de-formats it before handing it back __columnPrefixerEngine() - which loops through a standard dataset and adds or strips column prefixes I also overrode the Model::save() and Model::saveAll() methods to prefix the inbound data prior to saving (calling the appropriate parent method), and then strip the prefixes from the outbound data returned (for save() - saveAll() doesn't return data). And afterFind() calls the prefixer to strip prefixes from returned data. Modifying beforeFind() was interesting (yay regular expressions!), but again, Cake does such a nice job of standarizing the data format prior to hitting the database, this was actually pretty easy. The conditions had to be looped through to sub occurrences of Model.field and make them Model.prefix_field (with a check to make sure if its already got a prefix, it gets left alone - in fact, all of these methods do that in case back end code calls multiple methods on the same dataset). Fields are order are easy, and I'm going to look at the joins next. I also converted my previous beforeSave() for custom created/modified fields to play nicely with these new methods, and it gets called in the save()/saveAll() methods after the prefixer but before sending the data to the parent method. I still need to look through the delete operations, and make sure that all the various save/update/find operations funnel through the methods, but I'm really happy with this approach, not to mention its been a great Cake learning experience. --~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---
