You don't mention what DB Server you are using so I'll preface this with this solutions only works with db's that support triggers.
This sounds like a problem with the DB not necessarily with cake, However I would agree that it would be nice to have some variables you could specify these fields names with. In solving our problem with the DB this follows a pattern that I would use when more than one application access the DB directly. The problem with allowing this is it makes it difficult to schedule and coordinate schema changes, because we don't always have control over the code of the other applications. This schema change pattern is 'rename column'. I'll say the original columns are 'originalcreated' and 'originalmodified' and the new columns that we need to rename them to are created and modified. The pattern is this. Add the new column 'created' and 'modified' as the proper datetime type. Sync the existing data in the table for all existing records. Update the new created and modified columns with the data in originalcreated and originalmodified. Add an 'update trigger' on the table that will update the columns that are null with the data in the columns that are not null. For instance if your cake app is updating then the created and modified columns would have data in them and the 'originalcreated' and 'originalmodified' columns would be null. (The null state is only in the in memory update record of the trigger. the fields on disk will probably never be null.) This check could be update the date that is older with the date that is newer. Now you have both applications that can use their own schemas and the db will keep the data in the schema in sync with the trigger. The applications run like this for one or two release cycles until the other application which can't change just yet updates its code. As soon as no other applications are referencing the originalcreated and originalmodified columns then you drop the trigger and the two old columns. And that is a rough outline of what you need to do. This sounds like a bit more work then most people want to put into maintaining their db's however it does work, and it free's you to continue migrating your schema without the fear of breaking some older peice of code. I use this pattern and many other DB schema change patterns with my db's primarily as a benefit to the customers who have all written custom reports directly against the db. This gives them one or to release cycles where they can update there reports from the soon to be deprecated columns to the new columns going forward. For more info on these db schema refactoring patterns check out this site: http://www.agiledata.org/essays/databaseRefactoring.html Happy baking! On Dec 28 2007, 7:08 pm, Robby Anderson <[EMAIL PROTECTED]> wrote: > Hi folks. Relatively new to Cake, and so far I'm really enjoying using > it. I built a mini-app over the last few days as a training exercise > that would have normally taken a few weeks in plain PHP. :) > > My issue is this. I have a legacy database that I'm working with, and > I'm building a Cake app to use that legacy DB. Because there are other > applications that still use the DB, I can't change the field names to > use the standard cake conventions. This isn't a problem for the most > part, since the model can be configured to handle most of the changes > (table names, primary keys, associations) ... except (at least as far > as I've been able to determine) the 'created' and 'modified' columns. > > I dug through the 1.2 source, and found the code blocks in the Model > class that look for those columns (lines 1092 - 1111 and lines 1142 - > 1145 for those that are interested). They're currently hardcoded. I > could easily create new model properties to handle variable column > names (something like model->createdColumn and model->modifiedColumn > that could be set akin to the model->useTable and model->primaryKey > properties) on a model by model basis, that would default to the > current 'created', 'modified' and 'updated' column names. Before doing > so, my questions are thus: > > a) I'm using the 1.2 beta - if I go the route of changing the base > Model class, I guess I'd have to make sure to update the model > whenever I update my cake version. I tried to see if there was a > better way to deal with this specific change (I'm usually hesitant to > update lib for this very reason), but couldn't figure one out. Is > there something obvious I missed? (Or has someone already done > something like this for these columns?) > > b) If I did go ahead and make this change, would this be something > useful to submit as an enhancment ticket? (I looked, but didn't see > any tickets with this feature already). > > Thanks, > > -r --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
