Update of trac.ini occurs frequently when an order of the custom-made field is changed.

[wadatka]

Update of trac.ini occurs only the number of a customfield when an order of the custom-made field is changed.
So, when there is the custom-made field in large quantities, It takes time long till completion of processing.
The same phenomenon occurs also at the time of deletion of the customfield.

The following patch fixes this issue:

customfieldadmin.py

@@ -85 +85 @@
                         raise TracError, 'No custom field selected'
                     for name in sel:
                         cfdict =  {'name': name}
-                        cfapi.delete_custom_field(cfdict)
+                    cfapi.delete_custom_field(cfdict)
                     req.redirect(req.href.admin(cat, page))
 
                 elif req.args.get('apply'):
@@ -101 +101 @@
                         if cur_cf.has_key('options'):
                             if cur_cf.get('optional', False):
                                 cur_cf['options'] = [''] + cur_cf['options']
-                        cfapi.update_custom_field(cur_cf)
+                    cfapi.update_custom_field(cur_cf)
                     req.redirect(req.href.admin(cat, page))
 
             cf_list = []

[osimons]

I don't think you can take cfdict / cur_cf out of the loop and delete/update it afterwards? If so you would only do the change for the last item in the selection - all but the last selected field would be ignored.

I can visualize the need for some optimization in the case of lots of changes, as you are correct in that it is not so efficient to fully make each change, and reorder and commit to file for each one. It simplifies the code and API, but it is not very efficient.

Also, seeing that each write to trac.ini triggers a Trac env reload, you may also get environments with non-complete states (just some fields deleted or just some fields in new order). Usually quite harmless, but for a site under heavy load with many concurrent requests the high number of writes will trigger a large number of reloads which generally impacts the performance of the whole site for the duration of the custom field admin request.

Perhaps some sort of transaction handling in the API may be useful, something that skips clean/reorganize steps in mid-transaction and only commits everything at the end?

[Ryan J Ollos]

Will fix when reimplementing in ​trac:#11469.