Modify

Opened 3 years ago

Last modified 2 years ago

#9173 new defect

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

Reported by: wadatka Owned by: osimons
Priority: normal Component: CustomFieldAdminPlugin
Severity: normal Keywords:
Cc: Trac Release: 0.11

Description

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

     
    8585                        raise TracError, 'No custom field selected' 
    8686                    for name in sel: 
    8787                        cfdict =  {'name': name} 
    88                         cfapi.delete_custom_field(cfdict) 
     88                    cfapi.delete_custom_field(cfdict) 
    8989                    req.redirect(req.href.admin(cat, page)) 
    9090 
    9191                elif req.args.get('apply'): 
     
    101101                        if cur_cf.has_key('options'): 
    102102                            if cur_cf.get('optional', False): 
    103103                                cur_cf['options'] = [''] + cur_cf['options'] 
    104                         cfapi.update_custom_field(cur_cf) 
     104                    cfapi.update_custom_field(cur_cf) 
    105105                    req.redirect(req.href.admin(cat, page)) 
    106106 
    107107            cf_list = [] 

Attachments (0)

Change History (1)

comment:1 Changed 3 years ago by 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?

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.