8 replies to this topic

[alanfluff]

I have setup a simple tagging facility.

Afterwards I saw Nico's BundleBlog and noted it uses /tags/.

So I decided to change my setup from references to fields, templates, etc that were 'tags' to 'tagging'.

I used 'Edit field: tags > Duplicate/clone this field'. That gave me 'tags_1'.

I then edited 'tags_1' and went to rename it to 'tagging' and hit an error, PW said this name already existed. It seems from my trial/error/learn process I have ended up with at least two fields in my database (seen via MySQL) that aren't listed under Amin > Setup > Fields and one of those is called 'tagging'.

What is the best way to clear old/unused things, or, is this an edge case and it's only my trial and error steps that have led to this odd situation and ought I do make a new PW install and manually copy settings over. I don't mind doing that at all, my only concern is that I'd like to learn from this so were this a larger site I could perhaps recover in a more subtle (and quicker) way.

Thanks in advance for any pointers.

PS: The error is Table 'tmp_field_tagging' already exists

PPS: I've got around this by using the new name of 'tagged' instead of 'tagging', but I'd love to learn if defunct bits of my database can be safely cleared out somehow, e.g. I now have these four fields and yet only one will be used.

PPPS: Thinking about this, I will need to learn how to clear out old unused db items as I will be using Nico's Blog Module and that will need 'tags' to be gone. On reflection I think I was caught out by this/surprised as I assumed deleting a field would delete part fo the db that had been created to represent that field.

Edited by alan, 30 March 2012 - 10:17 AM.

[Soma]

Could it be that the field is system thus not visible by default. Try setting the filter to show system fields too.

[alanfluff]

Thanks for the suggest Soma, I tried that already and it is still not shown. I edited my post above and added "...I assumed deleting a field would delete the part of the db that had been created to represent that field..." and as well as the specific problem/clean-up I need to do, generally, is it normal/safe (I have no clue) for tables to be left behind? E.g. in MySQL I can see:

field_tagged
field_tagging
field_tags_alan

and in the Admin as I read down it goes:

sidebar
summary
tagged
title
?

[Soma]

NO it's not Most likely it's due to some excessive trying... If you delete a field the table will get deleted too.

[alanfluff]

Excessive trying, that sounds like me One day I hope to upgrade to excessive succeeding...

Btw, those things called:
field_tagged
field_tagging
field_tags_alan
are, I believe, MySQL tables not fields (PW naming convention).

[Soma]

What "flags" do they have that don't show in the admin field list? Are they used in any fieldgroup?

You can delete them manually, in the tables fieldgroup_fields first (look for id) and fields table, then the table of the field itself field_x.

Edit:
Though I also after excessive coding, trying got this issue ones, I delete the table and it's references manually.
BUt maybe would be good to know what the problem could be that this happens.

[alanfluff]

What "flags" do they have that don't show in the admin field list? Are they used in any fieldgroup?
You can delete them manually, in the tables fieldgroup_fields first (look for id) and fields table, then the table of the field itself field_x.

I don't see any references to "flags"? I'm using Navicat.app GUI which shows me this, and if I understand it correctly if I can't work out if they appear in fieldgroup_fields then I can't safely delete them do you think?

BUt maybe would be good to know what the problem could be that this happens.

Yes, I think so.

[Soma]

This is just the data table of the field. field_x table. The fields table holds the information (title etc) of the field and has flags column.

If the field is not attached to any template there will be no relation entry in the fieldgroups_fields. So you could next go to the fields table and delete the field you want to delete. Then the data table of the field itself (field_xxx).

[alanfluff]

Thanks Soma, I found both the tables I thought I didn't need or want were indeed not listed by name etc in table fields and so I went ahead and deleted both tables. All still working AOK.

Thanks very much for your help. I don't know if a database administrator would worry about old tables getting left behind or not, if they would then perhaps this ought to be added somehow as a 'todo' on github passed to Ryan to decide on priority etc? If there's anything I can do to help (I doubt it as I have too few synapses then I'd be happy to, I could at least test new builds to see if I can break them