Merge from conversation does not populate global context

[Gavin Donald]

I am not sure what I am doing wrong with this one, I have conversations in other parts of the application working OK but in this case it fails.

1. A conversation event is fired with three parameters (htMapper:HtMapper , htDay:HtDay, date:Date) which opens a dialog;
2. The user types into a text field and presses save;
3. An HtDay and a HtNote are created as this is the first time the dialog is opened and they do not yet exist in the database;
4. The HtNote is sent to the server, the htNote and the htDay to which it belongs are saved and returned;
5. Spring.getInstance().getContext(contextId).meta_end(true) is called and the dialog is closed.
   

I see the following in the log which looks like a merge has occurred:

mergeCollection: org.granite.tide.collections::PersistentCollection [] previous org.granite.tide.collections::PersistentCollection []
mergeCollection result: org.granite.tide.collections::PersistentCollection []
mergeEntity result: uk.co.prodia.habittracker.persistence.entity::HtMapper:1 (global)
mergeEntity result: uk.co.prodia.habittracker.persistence.entity::HtDay:121 (global)
mergeEntity result: uk.co.prodia.habittracker.persistence.entity::HtNote:78 (global)

but when I next use the htMapper it does not contain the htDay (which contains the htNote). The eventListener on the htMapper.htDays also does not fire.

Does anyone have any idea why the merge looks like it occurs but I don't seem to have the HtDay?

[wdrai]

Can you check that your new HtDay and HtNote have a uid before they are copied in the conversation

[Gavin Donald]

I have been trying quite a few things as your remark got me thinking about some other things and I am a little further ahead. The UID's are set when the objects are created but the HtDay and the HtNote can both be created inside of the conversation and so are not always passed into it, I assume that is not likely to be the problem.

Currently the results are pretty random after saving. A successful merge occurs about 90% of the time. The other 10% of the time the event listener on the htMapper.htDays does fire and although the uids are correct the htDay.id is not set. I have attached a log file with the org.granite.* enabled in case it is of any use. It shows that:

1. DayNotePm.onSave() is called - line 1;
2. DayNotePm.getHtDay() creates a new HtDay with its UID set - line 5;
3. Granite sends the htNote to the server;
4. DayNotePM.onSavedHtNote() is called as the Granite resultHandler and the htDay.uid and the htNote.uid are correctly set - line 81;
5. Granite begins to merge the contexts;
6. DateBoxPM.onHtDaysChange() is called with an event.kind of ADD but the htDay.id is not set although the htDay.uid is correct - line 135.

I must be missing something silly but I can't see what it is at the moment.

Please ignore any ERROR level logging, there are no errors I just use that while developing to give syntax highlighting in a log viewer, in fact you can find the entry points to my methods by searching for 'ERROR' in the log file.

[Gavin Donald]

When things work correctly for me I can see that the log file is slightly different. Here is the relevant snippet that works (equivalent to lines 134 to 157 in the previously attached log file):

[DEBUG] | org.granite.tide.data.EntityManager | mergeCollection: org.granite.tide.collections::PersistentCollection [uk.co.prodia.habittracker.persistence.entity::HtDay:298 (NoteConversationPM.CONVERSATION_EDIT_DAY_NOTE-1)] previous org.granite.tide.collections::PersistentCollection []
[DEBUG] | org.granite.tide.data.EntityManager | mergeEntity: uk.co.prodia.habittracker.persistence.entity::HtDay:298 (NoteConversationPM.CONVERSATION_EDIT_DAY_NOTE-1) previous null
[DEBUG] | org.granite.tide.data.EntityManager | mergeCollection: mx.collections::ArrayCollection [] previous null
[DEBUG] | org.granite.tide.data.EntityManager | mergeCollection result: mx.collections::ArrayCollection []
[DEBUG] | org.granite.tide.data.EntityManager | mergeCollection: mx.collections::ArrayCollection [] previous null
[DEBUG] | org.granite.tide.data.EntityManager | mergeCollection result: mx.collections::ArrayCollection []
[DEBUG] | org.granite.tide.data.EntityManager | mergeEntity: uk.co.prodia.habittracker.persistence.entity::HtNote:255 (NoteConversationPM.CONVERSATION_EDIT_DAY_NOTE-1) previous null
[DEBUG] | org.granite.tide.data.EntityManager | mergeEntity result: uk.co.prodia.habittracker.persistence.entity::HtNote:255 (global)
[DEBUG] | org.granite.tide.data.EntityManager | mergeEntity result: uk.co.prodia.habittracker.persistence.entity::HtDay:298 (global)
[INFO] | uk.co.prodia.habittracker.pm.impl.component.tracker.dateBox.DateBoxPM | Entered function onHtDaysChange
[DEBUG] | uk.co.prodia.habittracker.pm.impl.component.tracker.dateBox.DateBoxPM | event.kind [add]
[DEBUG] | uk.co.prodia.habittracker.pm.impl.component.tracker.dateBox.DateBoxPM | htDay [298] [8D7DA2C3-7F6D-777D-692C-A3AF028AEC19] has [1] htNotes

In this case Granite merges the collection AND the entities beforecalling the onHtDaysChange event handler.

In the ones that fail Granite merges the collection, then the event handler is called and then Granite merges the entities. This means that the event handler does not get the whole of the merge. The problem is I don't know what I am doing to cause this behaviour.

[Gavin Donald]

I couldn't find the real reason for this issue in my code, and so I came up with a hack. I put a timer in the onHtDaysChange handler that checked for the existence of the htDay.htNote after 500ms. This gives enough time for GraniteDS to complete its merge (at least on my machine) and solves the issue. Not a great solution but it seems to work OK. If anyone knows a better solution then I would be happy to hear about it.

[wdrai]

Very strange because the merge is completely synchronous, so there is no reason why a timer would change anything to the result.

It looks like a lazy collection loading is happening at some point, do you have something looking like this in your logs ?