[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