Got ugly traceback when deleting VM

[broder]

I have no idea what this means or what would cause it. Attempting the delete again worked, so I don't know, but

Uh-oh!  We experienced an error.'
Please email xvm-dev@mit.edu with the contents of this page.'
----
(IntegrityError) update or delete on "machines" violates foreign key constraint "machine_access_machine_id_fkey" on "machine_access"
DETAIL:  Key (machine_id)=(436) is still referenced from table "machine_access".
 'DELETE FROM machines WHERE machines.machine_id = %(machine_id)s' {'machine_id': 436L}
----
Traceback (most recent call last):
  File "/var/www/sipb-xen-www/main.py", line 636, in __iter__
    output = fun(self.username, self.state, fields)
  File "/var/www/sipb-xen-www/main.py", line 323, in command
    d = controls.commandResult(username, state, fields)
  File "/var/www/sipb-xen-www/controls.py", line 262, in commandResult
    deleteVM(machine)
  File "/var/www/sipb-xen-www/controls.py", line 202, in deleteVM
    transaction.commit()
  File "/usr/lib/python2.4/site-packages/SQLAlchemy-0.3.10-py2.4.egg/sqlalchemy/orm/session.py", line 71, in commit
    self.session.flush()
  File "/usr/lib/python2.4/site-packages/SQLAlchemy-0.3.10-py2.4.egg/sqlalchemy/orm/session.py", line 319, in flush
    self.uow.flush(self, objects)
  File "/usr/lib/python2.4/site-packages/SQLAlchemy-0.3.10-py2.4.egg/sqlalchemy/orm/unitofwork.py", line 210, in flush
    flush_context.execute()
  File "/usr/lib/python2.4/site-packages/SQLAlchemy-0.3.10-py2.4.egg/sqlalchemy/orm/unitofwork.py", line 400, in execute
    UOWExecutor().execute(self, head)
  File "/usr/lib/python2.4/site-packages/SQLAlchemy-0.3.10-py2.4.egg/sqlalchemy/orm/unitofwork.py", line 1020, in execute
    self.execute_delete_steps(trans, task)
  File "/usr/lib/python2.4/site-packages/SQLAlchemy-0.3.10-py2.4.egg/sqlalchemy/orm/unitofwork.py", line 1041, in execute_delete_steps
    self.execute_childtasks(trans, task, True)
  File "/usr/lib/python2.4/site-packages/SQLAlchemy-0.3.10-py2.4.egg/sqlalchemy/orm/unitofwork.py", line 1055, in execute_childtasks
    self.execute(trans, child, isdelete)
  File "/usr/lib/python2.4/site-packages/SQLAlchemy-0.3.10-py2.4.egg/sqlalchemy/orm/unitofwork.py", line 1020, in execute
    self.execute_delete_steps(trans, task)
  File "/usr/lib/python2.4/site-packages/SQLAlchemy-0.3.10-py2.4.egg/sqlalchemy/orm/unitofwork.py", line 1043, in execute_delete_steps
    self.delete_objects(trans, task)
  File "/usr/lib/python2.4/site-packages/SQLAlchemy-0.3.10-py2.4.egg/sqlalchemy/orm/unitofwork.py", line 1026, in delete_objects
    task.mapper.delete_obj(task.polymorphic_todelete_objects, trans)
  File "/usr/lib/python2.4/site-packages/SQLAlchemy-0.3.10-py2.4.egg/sqlalchemy/orm/mapper.py", line 1320, in delete_obj
    c = connection.execute(statement, delete)
  File "/usr/lib/python2.4/site-packages/SQLAlchemy-0.3.10-py2.4.egg/sqlalchemy/engine/base.py", line 517, in execute
    return Connection.executors[c](self, object, *multiparams, **params)
  File "/usr/lib/python2.4/site-packages/SQLAlchemy-0.3.10-py2.4.egg/sqlalchemy/engine/base.py", line 557, in execute_clauseelement
    return self.execute_compiled(elem.compile(dialect=self.dialect, parameters=param), *multiparams, **params)
  File "/usr/lib/python2.4/site-packages/SQLAlchemy-0.3.10-py2.4.egg/sqlalchemy/engine/base.py", line 568, in execute_compiled
    self._execute_raw(context)
  File "/usr/lib/python2.4/site-packages/SQLAlchemy-0.3.10-py2.4.egg/sqlalchemy/engine/base.py", line 581, in _execute_raw
    self._execute(context)
  File "/usr/lib/python2.4/site-packages/SQLAlchemy-0.3.10-py2.4.egg/sqlalchemy/engine/base.py", line 599, in _execute
    raise exceptions.SQLError(context.statement, context.parameters, e)
SQLError: (IntegrityError) update or delete on "machines" violates foreign key constraint "machine_access_machine_id_fkey" on "machine_access"
DETAIL:  Key (machine_id)=(436) is still referenced from table "machine_access".
 'DELETE FROM machines WHERE machines.machine_id = %(machine_id)s' {'machine_id': 436L}

----

[ecprice]

Probably fixed in r589.