Sackgesicht VIP
Total posts: 1,636
24 Июль 2013 21:09

I have a type, where i deleted some fields.

Now i noticed that even after editing a record of this type, it still keeps the former info of the deleted fields in the "fields" column of the #__js_res_record table

Последние изменения: 08 Апр 2014


Sergey
Total posts: 13,748
24 Июль 2013 23:50

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.


Sackgesicht VIP
Total posts: 1,636
25 Июль 2013 01:57

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.


Sergey
Total posts: 13,748
26 Июль 2013 01:55

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


Sackgesicht VIP
Total posts: 1,636
26 Июль 2013 17:58

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


Sergey
Total posts: 13,748
29 Июль 2013 02:32

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.


Sackgesicht VIP
Total posts: 1,636
29 Июль 2013 02:37

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


Sergey
Total posts: 13,748
29 Июль 2013 02:41

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


Sackgesicht VIP
Total posts: 1,636
29 Июль 2013 02:52

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 ...


pepperstreet VIP
Total posts: 3,837
10 Окт 2013 16:40

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 ... ;-)


Sergey
Total posts: 13,748
10 Окт 2013 23:28

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 :)


pepperstreet VIP
Total posts: 3,837
11 Окт 2013 05:18

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?!


londoh VIP
Total posts: 137
11 Окт 2013 05:55

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.


justanotherguy
Total posts: 88
27 Март 2014 18:13

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.


justanotherguy
Total posts: 88
27 Март 2014 18:26

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.


Sergey
Total posts: 13,748
28 Март 2014 07:27

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

I'll check it.


justanotherguy
Total posts: 88
07 Апр 2014 23:32

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?


Sergey
Total posts: 13,748
08 Апр 2014 06:01

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

Работает на Cobalt