#js_res_record keeps old data

Yes that is correct. Unfortunately this is how it works. Once saved it can be only updates. This is special algorithm for field editing rights. For example user may add field YEAR but cannot edit it. So we have to keep it's value when we edit record.

I am referring to deleted fields. I will delete the field from the type, so this field does not exist anymore. If i recreate it again, it will get a different ID.

Therefore when editing, no need to save it (the NON existing field) anymore.

I noticed it, since I removed an upload field and it still keeps all the data (from 20+ uploaded files) there.

I can only think of a new tool like clean records of deleted fields.

... and save at edit time only existing fields ...

I almost finished as i have discovered that it will delete even values of unpublished fields. But that sometimes wrong. The fact I unpublished field does not mean I do not want to publish it later.

It should not delete unpublished fields.. only deleted (not existing anymore)

But then I have to run additional йшукшуы to check if that field is not there because it is unpublished or because it is deleted.

It should be a maintenance tool -- maintenance can run for a while ..

actually it should run (or add least inform the admin to do a maintenance run) after deleting a field. Keep in mind that a big number of records might consume a lot of memory (from the experience of the index tool). Better processing small batches ...

What is the current status? I agree with "Sackgesicht"... deleted fields don´t have to be kept. Still don´t get the idea why this should be an extra tool!? Delete is delete... gone... never seen again... history ... ;-)

What if you have 300k articles and delete field? Every article have to be opened, fields data converted to array, key deleted, converted to string and save. There is no server that can do that. Even with 10k articles.

And what is wrong if it stays there? Let it be there no problem. it does not break site work :)

What if you have 300k articles and delete field? Every article have to be opened, fields data converted to array, key deleted, converted to string and save. There is no server that can do that. Even with 10k articles.

Take a look at ANY other article/item list in backend. You never deal with such a big amount of data in one go! There is a pagination and a limit... even in Cobalt.

In general, you select several articles on one page (1-10), or select a whole page with the "column" checkbox. (maybe 10-50, or let it be 100). That is the real world.

Common tasks: - remove demo data! - delete older/orphan articles that - clear a certain category

Not to mention other common basic actions: - move - copy

This is all really basic must-have stuff.

What if you have 300k articles and delete field? Every article have to be opened, fields data converted to array, key deleted, converted to string and save. There is no server that can do that. Even with 10k articles.

And what is wrong if it stays there? Let it be there no problem. it does not break site work

It is simply nonsense and stupid to keep such "dead bodies" ;-)

Seriously, why should one keep deleted data?! Especially when you have a big article count... or the articles are community driven... they will grow and grow and grow (BTW, would be nice to have an archive and export manager)

"does not break the site": - Really no impact on DB and search etc.? - at least it has an impact on site/DB backups! Why backup old deleted data with the current and important articles?!

I dont think that the point about pagination is relevant in this case where admin has deleted a field.

But nevertheless I very much agree that the system should not be preserving orphaned data in the database.

Quite simply: If the field has been deleted the data must deleted along with it. > Delete is delete... etc

I can somewhat understand sergeys point about load, but this is an admin only task, which is only going to be run very infrequently. So warn admin to go and get a cup of coffee.

I noticed this data being kept some while back and had assumed that removing it was covered by the re-index tool - so was my assumption incorrect?

And I must ask that question because I've never been able to get re-index tool to run it just glares at me for a while and nothing happens. But maybe thats the subject for a separate thread.

I also would like a way to delete the old DB data. Either upon del of field or a DB tool. Either is fine with me. A reason to want to delete old DB data would be if sensitive information was entered and later the admin realized he would rather not have such info in the DB. Once the field is deleted the date would remain. Admin would prefer sensitive info from deleted field be scrubbed from the DB.

I also notice that since I use the audio upload field that if I delete a record the audio files uploaded stay on the server. Running the existing tools (clean unsaved or clean deleted files) do not delete the audio. As the audio is neither unsaved nor deleted. This tool that clean the DB could also remove any and all audio files that are not currently tied to a record. This would save a ton of space.

Clean unsaved files should actualy delete all files that are not tied to articles.

I'll check it.

Sergey Clean unsaved files should actualy delete all files that are not tied to articles.

I'll check it.

What did you find?

Sergey I almost finished

Is there a way to remove orphaned data from the database or is this still in the works?

I checked and when I delete article all it's fiels are deleted as well.