2009-02-07:
[10:20] <decke> zumbrunn: good morning... i unserstand my invalidate() problem a bit better now ...[10:20] <decke> looks like helma has multiple copies of the same HopObject in his object cache and invalidate() only invalidates one of them[10:22] <zumbrunn> how come there are multiple copies in the object cache?[10:22] <decke> don't know but it looks like this..[10:23] <decke> there are user pages in a collection at root.np (HopObject User)[10:23] <decke> and also in a lot of other places and also in an admin area where you can edit user data[10:24] <decke> and another system does an http request on /np/<user>/invalidate if it changes something in the database[10:24] <decke> now if i change something in the database and call /np/<user>/invalidate through the browser nothing happens in the admin area[10:25] <decke> there is the old data... so it looks to me as there are more then one object from the same db row[10:26] <zumbrunn> maybe it isn't the same HopObject, but two different HopObjects somehow separately mapped to the same data in the db?[10:27] <zumbrunn> otherwise it's probably a bug, I guess[10:28] <decke> [object User] 741[10:28] <decke> in both cases[10:28] <decke> so it's the same HopObject i guess[10:28] <decke> the first is res.write(object); the second res.write(object._id);[10:29] <decke> but the first is stored in session.data somewhere[10:40] <decke> it looks interesting...[10:42] <decke> if i add the object to session.data and then change something in the db and call invalidate on root.np.get("nick").invalidate();[10:42] <decke> the session.data.whatever contains old data and knows nothing about invalidate[10:42] <decke> i'll see if i can create a mini test case for that....[10:42] <zumbrunn> kind of like a closure effect going on there[10:43] <decke> don't know if it's the bug, that objects should never be duplicate[10:44] <decke> or if the invalidate should call all of them...[10:44] <decke> or it's forbidden to use session.data and reference HopObjects there[10:45] <zumbrunn> or a handy feature, now that we know it behaves like that[10:46] <decke> i've had 2 more of them that i already riped out of the code....[10:46] <decke> because it broke the registration badly...[10:46] <decke> seems like session.data is kinda special
In the channel now:
Logs by date: