Quote from: sottwell at Aug 08, 2006, 01:47 AM
While creating a new table to handle a page hit counter plugin, I noticed that the database is inconsistant in its field names. For example, you’ll find contentType, but pub_date. This isn’t really all that important, but it does make for a more difficult time coding queries for modules and such; you have to keep checking to make sure you got the fieldname right. This isn’t really a complaint or a request, just an observation; something to maybe think about.
Yes, and one of my pet peeves. When designing the Tattoo data structure back in Nov/Dec, I originally renamed all of the fields to use less abbreviations and to consistently use underscores to separate words. This consistency was necessary at the time so that the engine I was building it with (Propel) could produce proper method names for the accessor methods. However, when I refactored the data model for MODx 1.0, I opted for keeping the field names the same as they were (unless they were moving to a different table or something) for compatibilities sake.
However, after some more thought and coding, I believe it would be better to go with a more consistent naming convention in 1.0 and make either very clear in the migration guide that anything dependent on former tables/field names will need to be reviewed and updated for 1.0, or produce plugins that can provide results of the new data in the format of the old data, so many, if not all older, immutable components could still work.
[NOTE: by immutable, I mean that the component does not attempt to write data back to the tables; all mutable components would probably require migration, though theoretically, these could also be handled by some legacy support components.]
☆ A M B ☆
MODX Staff