#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 17 years ago by
Status: | new → assigned |
---|
comment:2 Changed 17 years ago by
Did you manage to explain or solve you problem, or do you have more information to help me look into it?
comment:3 Changed 17 years ago by
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 17 years ago by
Resolution: | → worksforme |
---|---|
Status: | assigned → closed |
Hmm...
- 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.
- You actually resolved it by clearing data and all is now working well.
- 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 17 years ago by
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 17 years ago by
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... :-|
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: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.