[orm-devel] Bug or feature in relationships.py
Michael Watkins
orm-devel@mailman.tux4web.de
Mon, 17 Feb 2003 13:17:49 -0800
Greetings all -
Warning, its been a little while since I last dug about in ORM so if I
sound a little off base or deranged, please forgive me in advance. I may
just need a gentle nudge here.
I had to dust off some web-forms code I wrote a while ago using ORM and
just realized (I think) that there is a bug, or a misunderstood (on my
part) feature in how the one2one relationship is implemented.
In reading my old code it looks like I set a "lookup" relationship between
a parent object (say a document) and a status object (a small table of
status items). When you change an existing parent object by reassigning a
different status object, the change is made but the net effect is the row
from the status table is deleted.
Line 172 of relationships.py in the set method of one2oneColumn contains:
if self._data: self._data.delete()
This is a slightly different use case than what (I think) one2one
envisions. The example Diedrich uses is a photograph to a person. I guess I
can see deleting a photograph row if the persons photo is being replaced
with another, so the delete that happens in lock step with the status_id
attribute reassignment could make sense.
But it does not make sense in the scenario I present, where a Document
might have a number of attributes which are simple lookups into other
tables. To flesh this out more
Document has
creation_date
content
status_id
type_id
subject_id
Status has
id
code
description
Type has
id
code
description
Subject has
id
code
description
When a document has its status changed, the relationship between Document
and a row in Status should change, but no rows in Status should be deleted.
Really the relationship between Document and Status is one2many i.e. one
Status row relates to zero, one or many Document rows, but frequently you
would not look at the relationship from that angle.
one2one functionally delivers all that is needed with the important
exception of that delete happening on line 172. I guess I could just
subclass it and modify its behaviour for myself but I imagine I'm not the
only person with this need so here I am raising this.
Mike