The Development Team Logic on Database Upgrades

I am not on the development team, but using logic, I would imagine that the upgrades are done by changing some attributes to tables or adding or removing tables. wp_posts is a major table and any changes to that would most likely be small and not affect the new row you add to it.

That being said, if you are adding a new row to the table, why not add it as a new row in a new table? It is most likely being called by a plugin you are using and that way you ensure that upgrades won’t affect the row you added. It requires a few more lines of SQL, but is safest. Sorry if this doesn’t help, just thinking out loud….

Trent

No, what you suggest is definitely something I’ve been considering. But I feel like it would end up being bad database architecture since the data in the row I want to add really has a one-to-one relationship with each post.

Just to explain (if you’re curious) I write a blog that is fictional in nature and I wanted to distinguish between the time-date that a post was published and the time-date that the events described occurred. I guess that really means that its not a one-to-one relationship. Since many posts could describe events that occur at one particular moment in time but in different places or from different perspectives.

Shoot. I was thinking out loud, too and now I’m confused. Now I think you might be right. An extra table with a date for each post_id might make the most sense.

Could you use a custom field?

Thanks, jabecker. I could use a custom field with the exception that the database then won’t know that the information in the field is a date. I have to consider that. It could make some things more difficult down the road.