Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Bug(?): Client side ResultSet does not regard nested relatedUpdates

    Hi Isomorphic,

    I have the following situation in current 4.1d:
    1) My serverside DMI executes a request (DB-changing).
    2) Upon successful execution it calls a helper method this.
    3) The Helper1 executes its request (DB-changing).
    4) Upon successful execution Helper1 calls a Helper2 method.
    5) The Helper2 executes its request (DB-changing).
    6) Helper1.addRelatedUpdate (Helper2.response)
    7) DMI.addRelatedUpdate (Helper1.response)

    In the client, the nested response of Helper2 is not used (I have ResultSet and RPCManager logging set to Debug in the Console)

    My Response in the RPC-Tab of the Delevoper Console looks like this (watch for the two "relatedUpdates"):
    Code:
    [
        {
            data:[
                {
                    USER_ID:1012, 
                    LEAD_ID:1
                }
            ], 
            invalidateCache:false, 
            isDSResponse:true, 
            operationType:"remove", 
            queueStatus:0, 
            [B]relatedUpdates:[
                {
                    relatedUpdates:[[/B]
                        {
                            endRow:1, 
                            dataSource:"V_LEAD_PICKED", 
                            totalRows:1, 
                            isDSResponse:true, 
                            invalidateCache:false, 
                            status:0, 
                            operationType:"update", 
                            startRow:0, 
                            data:[
                                {
                                    ...data1...
                                }
                            ]
                        }
                    ], 
                    dataSource:"T_LEAD_HISTORY", 
                    isDSResponse:true, 
                    invalidateCache:false, 
                    status:0, 
                    operationType:"update", 
                    data:[
                        {
                            ...data2...
                        }
                    ]
                }
            ], 
            status:0
        }
    ]
    The DSRequest in the RPC-Tab of the Developer Console looks like this:
    Code:
    {
        dataSource:"V_LEAD_MATCHED_UNDISMISSED", 
        operationType:"remove", 
        operationId:"acceptLead", 
        data:{
            USER_ID:1012, 
            LEAD_ID:1
        }, 
        showPrompt:true, 
        oldValues:{
            USER_ID:1012, 
            LEAD_ID:1
        }, 
        requestId:"V_LEAD_MATCHED_UNDISMISSED$62718", 
        fallbackToEval:false, 
        lastClientEventThreadCode:"MUP6", 
        bypassCache:true
    }
    I'm pretty sure that the ResultSet discards the 2nd RelatedUpdate.

    I can "repair" the situation by doing the following:
    1) My serverside DMI executes a request (DB-changing).
    2) Upon successful execution it calls a helper method this.
    3) The Helper1 executes its request (DB-changing).
    4) Upon successful execution Helper1 calls a Helper2 method.
    5) The Helper2 executes its request (DB-changing).
    6) Helper1.addRelatedUpdate(Helper2.response)
    7) DMI.addRelatedUpdate(Helper1.response) (until now as above)
    8) foreach (innerRelatedUpdate : Helper1.getRelatedUpdates) -> DMI.addRelatedUpdate(innerRelatedUpdate).

    This has the expected result and the client-side widgets update their data as expected, BUT I have the data1 twice in the response, which is definitely not correct or necessary.

    My Response in the RPC-Tab of the Developer Console in the 2nd case looks like this (watch for the two "relatedUpdates" and the two "...data1..."):
    Code:
    [
        {
            data:[
                {
                    USER_ID:1012, 
                    LEAD_ID:1
                }
            ], 
            invalidateCache:false, 
            isDSResponse:true, 
            operationType:"remove", 
            queueStatus:0, 
           [B] relatedUpdates:[
                {
                    relatedUpdates:[[/B]
                        {
                            endRow:1, 
                            dataSource:"V_LEAD_PICKED", 
                            totalRows:1, 
                            isDSResponse:true, 
                            invalidateCache:false, 
                            status:0, 
                            operationType:"update", 
                            startRow:0, 
                            data:[
                                {
                                    [B]...data1...[/B]
                                }
                            ]
                        }
                    ], 
                    dataSource:"T_LEAD_HISTORY", 
                    isDSResponse:true, 
                    invalidateCache:false, 
                    status:0, 
                    operationType:"update", 
                    data:[
                        {
                            ...data2...
                        }
                    ]
                }, 
                {
                    endRow:1, 
                    dataSource:"V_LEAD_PICKED", 
                    totalRows:1, 
                    isDSResponse:true, 
                    invalidateCache:false, 
                    status:0, 
                    operationType:"update", 
                    startRow:0, 
                    data:[
                        {
                            [B]...data1...[/B]
                        }
                    ]
                }
            ], 
            status:0
        }
    ]
    Could you please advise what the correct way of using the APIs is in this case?
    Is the discarding of the nested relatedUpdate a bug?
    If its not a bug, I think an additional API like DSResponse.removeRelatedUpdates() could solve the problem for me. I'd then pull my nested relatedUpdates to the top level and remove them afterwards.

    Thank you and best regards,
    Blama
Working...
X