Bug 607 - ID of transient object is 0 after becoming persistent
: ID of transient object is 0 after becoming persistent
Status: RESOLVED FIXED
: Helma
HopObject Functionality
: CVS trunk
: All All
: P1 normal
: 1.6.2
Assigned To:
:
:
:
  Show dependency treegraph
 
Reported: 2008-03-17 20:33 by
Modified: 2008-04-04 13:52 (History)


Attachments
Test app demonstrating the bug (5.81 KB, application/zip)
2008-03-27 11:08, tobi
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2008-03-17 20:33:14
Setting a property to a transient object leads to a "0" entry in the database
although the object is being made persistent during the same request:

var foo = new Foo;
var bar = new Bar; 
bar.foo = foo;        // bar.foo === 0
root.bars.add(bar);
root.foos.add(foo);
//bar.foo = foo;

Removing the comment signs from the last line enables a work-around. However,
there are some situations where this simply is not reasonable.

Moreover, I wonder if this bug was introduced lately because it happens in code
I did not touch for quite a while. (But I am not really sure.)

I can provide a test case if wanted.
------- Comment #1 From 2008-03-26 19:47:56 -------
That would be a pretty bad bug. I tried to reproduce this quickly, but it
worked for me. Can you provide a test app please?
------- Comment #2 From 2008-03-27 11:08:57 -------
Created an attachment (id=86) [details]
Test app demonstrating the bug


I think I found the reason for the 0 ids: in the test app I attached to this
bug there's the foo_id property mapped in Bar.properties which IMHO is causing
the bug.

When I remove the foo_id mapping I get the expected result, ie. correct ids.

However, this cannot be a work-around since I need to map the equvalent to
foo_id in my setup because it is used in a generic object mapping.
------- Comment #3 From 2008-04-01 15:03:57 -------
The problem is that this kind of relations can't work with non-persistent
objects that do not have a database id. So the workaround is to call
root.foos.add(foo) or foo.persist() before assigning bar.foo = foo.

I've changed Helma to throw an explicit error when it encounters a situation
like this. Fixing the problem in a deeper way would be really really hard.