Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We're retiring the forums!

The SilverStripe forums have passed their heyday. They'll stick around, but will be read only. We'd encourage you to get involved in the community via the following channels instead:

General Questions /

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

Force dev/build to drop unused columns?

Go to End

4 Posts   2287 Views


Forum Moderator, 1899 Posts

29 July 2010 at 9:10pm


I am getting a bit frustrated with backing up and restoring databases because (with mysql) I get a set of SQL inserts to run against the new database... so... in the situation where I had a field in a DataObject, then removed it, it is will still appear in the database export.

How can I stop this happening? any ideas?



Community Member, 7 Posts

30 July 2010 at 1:16am

Edited: 30/07/2010 1:16am


It sounds to me like all you have to do is manually drop the column(s) from the table(s) corresponding to the DataObject you have edited. Once this is done they would disappear from your backups (since they no longer exists).

/dev/build will not drop columns for you and can not (to my knowledge) be configured to do so. If you ask me, it is sound behaviour since it keeps you safe from loosing data in the case of typos and accidental removal of keys/values in $db or $has_one.


Community Member, 46 Posts

30 July 2010 at 1:18am

As I understand it, if you have removed a field in your DataObject model you will also have to manually drop the columns in the MySQL database table if you don't want them showing up in your SQL exports.

The SQL would be something like:

  DROP `MyLegacyField`

or you can use phpMyAdmin to drop the fields.


Forum Moderator, 1899 Posts

30 July 2010 at 1:22am

thanks for these guys, this is what I have done, and I do appreciate that most web developers would be happy with having old data swimming around. I am working with a very large database and this is not only confusing when looking at the data itself but it also increases the size quite alot.