Modify

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#2002 closed defect (worksforme)

Removed Fields causes sql errors.

Reported by: simon@… Owned by: osimons
Priority: high Component: CustomFieldAdminPlugin
Severity: critical Keywords:
Cc: Trac Release: 0.10

Description

When i remove a custom field created with this plugin, i get these sql errors afterwards when trying to view a ticket:

Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 406, in dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 237, in dispatch
    resp = chosen_handler.process_request(req)
  File "/usr/lib/python2.4/site-packages/trac/ticket/web_ui.py", line 286, in process_request
    ticket = Ticket(self.env, id, db=db)
  File "/usr/lib/python2.4/site-packages/trac/ticket/model.py", line 40, in __init__
    self._fetch_ticket(tkt_id, db)
  File "/usr/lib/python2.4/site-packages/trac/ticket/model.py", line 98, in _fetch_ticket
    (tkt_id,))
  File "/usr/lib/python2.4/site-packages/trac/db/util.py", line 50, in execute
    return self.cursor.execute(sql_escape_percent(sql), args)
  File "/usr/lib/python2.4/site-packages/trac/db/sqlite_backend.py", line 56, in execute
    args or [])
  File "/usr/lib/python2.4/site-packages/trac/db/sqlite_backend.py", line 48, in _rollback_on_error
    return function(self, *args, **kwargs)
OperationalError: no such column: value

Also in the list of custom fields in the admin-section, when i've removed the custom field i created, it manages to get back into the list.. When i refresh the list several times it randomly disappears again, just to reappear/re-disappear as i continue refreshing. This plugin made me not being able to view any tickets at all, so our companys trac installation is completely broken/unusable now :( Thanks in advance!

Attachments (0)

Change History (6)

comment:1 Changed 7 years ago by osimons

  • Status changed from new to assigned

Hi there, and sorry; just noticed the ticket now.

Re: the first (main) problem: The plugin only writes the settings to trac.ini, and they get handled by Trac just like a custom field entered manually in your config. I have never seen such an issue arise due to custom fields, and have not managed to recreate it - or even anything close to it. My best hunch is that the naming of your field somehow conflicts with Trac - see Trac ticket:1449 as an example of this (still unresolved). However, if you are able to provide more information, it might be possible for me to recreate this:

  • Trac version?
  • Name and type of your custom field?
  • Any other plugins?
  • Anything else working against your ticket data?

About the second issue, this is well-known, and there is also a warning on the plugin home page about this very thing. It is all descibed in ticket:3833 which has now finally been resolved for Trac 0.11dev (ie. trunk), but there will likely never be a fix for 0.10 users. If you run a typical setup like Apache/mod_python/Linux, you need to restart the server whenever you delete a custom field - or else the other processes are unable to clear the field from their settings correctly.

comment:2 Changed 7 years ago by osimons

Did you manage to explain or solve you problem, or do you have more information to help me look into it?

comment:3 Changed 7 years ago by simon@…

I didn't manage to fix the problem in any proper way. What i did to completely remove the custom field was to open up the trac.db with sqlite3 and drop the ticket_custom table and then re-create it again.

# sqlite3 /path/to/trac.db


sqlite> drop table ticket_custom;

sqlite> create table ticket_custom(name, value, ticket);

sqlite> .exit

comment:4 Changed 7 years ago by osimons

  • Resolution set to worksforme
  • Status changed from assigned to closed

Hmm...

  1. I can't see how the plugin could possibly create errors just by writing the settings to trac.ini as if they had been entered into the file manually.
  2. You actually resolved it by clearing data and all is now working well.
  3. As there is no further information (settings, database content and so on) on which to research the issue, it will likely never be explained or resolved in another meaningful way.

Therefore I might as well close this ticket as it is no point in it staying open - 'worksforme' seems to be the best option...

comment:5 Changed 7 years ago by anonymous

I guess the problem was that when you create a custom field, a new sql-field is created for every ticket in the trac.db to contain the value of the new field. When i removed the custom-field from the admin-section, i guess it did not remove the fields from the ticket-table in the db.

Since my trac-environment was more or less non-functional i upgraded to 0.11dev and skipped this plugin, so i can't recreate the issue or look at the db.. :(

comment:6 Changed 7 years ago by osimons

It could well have been some mixup caused by that second issue (ticket:3833) with multiple processes having a different view on the world. The handling of custom fields removed from trac.ini is all pure Trac which my plugin does not touch, so again nothing should be different than a manual addition and removal. And, normal Trac behavior is not to remove existing fields.

Anyway, it is converted to current 0.11dev + with that Trac environment reload issue now fixed in 0.11dev, there should not be any issues affecting the plugin. Hope you didn't skip the plugin because you think it is scary - it really shouldn't be... :-|

Add Comment

Modify Ticket

Action
as closed The owner will remain osimons.
The resolution will be deleted. Next status will be 'reopened'.
Author


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

 
Note: See TracTickets for help on using tickets.