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.

General Questions /

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

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

Force dev/build to drop unused columns?


Reply


4 Posts   1569 Views

Avatar
swaiba

Forum Moderator, 1805 Posts

29 July 2010 at 9:10pm

Hi,

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?

Barry

Avatar
charden

Community Member, 7 Posts

30 July 2010 at 1:16am

Edited: 30/07/2010 1:16am

Hello,

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.

Avatar
ryanwachtl

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:

ALTER TABLE `MyTable`
DROP `MyLegacyField`

or you can use phpMyAdmin to drop the fields.

Avatar
swaiba

Forum Moderator, 1805 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.