LAVA Scheduler (deprecated)

deleting a device_type fails

Reported by Paul Larson on 2011-10-18
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
LAVA Scheduler (deprecated)
Won't Fix
Medium
Unassigned

Bug Description

Looks like it's still referenced. I'm trying to simply change the name of snowball-sd to snowball_sd but when I tried to do that it created a new device_type instead. When trying to delete it, I get an error:

[Tue Oct 18 15:00:08 2011] [error] [client 75.27.138.6] IntegrityError: update or delete on table "lava_scheduler_app_devicetype" violates foreign key constraint "requested_device_type_id_refs_name_2f2696ac925e8aa7" on table "lava_scheduler_app_testjob", referer: http://validation.linaro.org/lava-server/admin/lava_scheduler_app/devicetype/
[Tue Oct 18 15:00:08 2011] [error] [client 75.27.138.6] DETAIL: Key (name)=(snowball-sd) is still referenced from table "lava_scheduler_app_testjob"., referer: http://validation.linaro.org/lava-server/admin/lava_scheduler_app/devicetype/

Paul Larson (pwlars) on 2011-10-18
Changed in lava-scheduler:
importance: Undecided → Medium
Michael Hudson-Doyle (mwhudson) wrote :

I noticed some wonkyness yesterday around the admin interface too (deleting devices fails too in similar ways).

Updating the name of a device type is going to be a bit tricky because it's the primary key of the table -- but I thought Django handled that.

You can always fix in with psql I guess :-)

Michael Hudson-Doyle (mwhudson) wrote :

OK, after a bit more poking I've come to the conclusion that we should not edit device_type ever.

Fortunately there's no real state in a device_type so we can add a type, move all references over to the new type and then delete the old one -- but do this using psql, not django.

W dniu 19.10.2011 04:32, Michael Hudson-Doyle pisze:
> OK, after a bit more poking I've come to the conclusion that we should
> not edit device_type ever.
>
> Fortunately there's no real state in a device_type so we can add a type,
> move all references over to the new type and then delete the old one --
> but do this using psql, not django.

Django allows the same thing to happen, see on_delete in the model docs.

Thanks
ZK

Michael Hudson-Doyle (mwhudson) wrote :

On Wed, 19 Oct 2011 08:57:15 -0000, Zygmunt Krynicki <email address hidden> wrote:
> W dniu 19.10.2011 04:32, Michael Hudson-Doyle pisze:
> > OK, after a bit more poking I've come to the conclusion that we should
> > not edit device_type ever.
> >
> > Fortunately there's no real state in a device_type so we can add a type,
> > move all references over to the new type and then delete the old one --
> > but do this using psql, not django.
>
> Django allows the same thing to happen, see on_delete in the model docs.

Huh? Which same thing do you mean? The bit you're replying to is
talking about modifying primary keys, which is clearly a sketchy thing
to be doing but Django reacts to very strangely.

I'm aware of on_delete -- it's documented as defaulting to CASCADE
though, which clearly isn't happening here (even though I think it's a
bonkers default).

Alan Bennett (akbennett) on 2013-06-11
Changed in lava-scheduler:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers