summaryRow problem with queueing

[claudiobosticco]

SmartClient Version: SNAPSHOT_v12.1d_2019-05-15/EVAL Development Only (expires 2019.07.14_07.21.56) Licensed to: Isomorphic Software (#ISC_EVAL_NIGHTLY)
and
SmartClient Version: v11.1p_2019-05-15/Enterprise Development Only (built 2019-05-15)

Hello, I've just found that when you have a summaryRowDataSource and issue a queue of operations on the grid/dataSource, the resultSet will trigger a summaryRow fetch for every operation, despite the queue.

Please try this test case:

isc.ListGrid.create({
    ID: "countryList",
    height:"100%", width:"100%", alternateRecordStyles:true, 
    dataSource: supplyItem,
    showGridSummary: true,
    summaryRowDataSource: supplyItem,
    summaryRowFetchRequestProperties: {operationId: "summary"},
    autoFetchData:true
})

The dataSource with the 'summary' fetch:

<DataSource isSampleDS="true"
    ID="supplyItem"
    serverType="sql"
    tableName="supplyItem"
    titleField="itemName"
    testFileName="/examples/shared/ds/test_data/supplyItem.data.xml"
    dbImportFileName="/examples/shared/ds/test_data/supplyItemLarge.data.xml"
>
    <fields>
        <field name="itemID"      type="sequence" hidden="true"       primaryKey="true"/>
        <field name="itemName"    type="text"     title="Item"        length="128"       required="true"/>
        <field name="SKU"         type="text"     title="SKU"         length="10"        required="true"/>
        <field name="description" type="text"     title="Description" length="2000"/>
        <field name="category"    type="text"     title="Category"    length="128"       required="true"
               foreignKey="supplyCategory.categoryName"/>
        <field name="units"       type="enum"     title="Units"       length="5">
            <valueMap>
                <value>Roll</value>
                <value>Ea</value>
                <value>Pkt</value>
                <value>Set</value>
                <value>Tube</value>
                <value>Pad</value>
                <value>Ream</value>
                <value>Tin</value>
                <value>Bag</value>
                <value>Ctn</value>
                <value>Box</value>
            </valueMap>
        </field>
        <field name="unitCost"    type="float"    title="Unit Cost"   required="true">
            <validators>
                <validator type="floatRange" min="0" errorMessage="Please enter a valid (positive) cost"/>
                <validator type="floatPrecision" precision="2" errorMessage="The maximum allowed precision is 2"/>
            </validators>
        </field>
        <field name="inStock"   type="boolean"  title="In Stock"/>
        <field name="nextShipment"  type="date" title="Next Shipment"/>
    </fields>
       <operationBindings>
       <operationBinding operationType="fetch" operationId="summary">
            <summaryFunctions>
                <unitCost>sum</unitCost>
            </summaryFunctions>
        </operationBinding>
    </operationBindings>
</DataSource>

Then execute this code:

isc.RPCManager.startQueue()
countryList.removeData({ itemID:3 })
countryList.removeData({ itemID:4 })
isc.RPCManager.sendQueue()

You'll see the queue with two requests, and then two fetches for the summary row:

[claudiobosticco]

Also, I don't know if and how may be related, but in my application, these multiple summary row fetches, sometimes trigger an apparently nonsense error:

2019-05-19T13:02:48,312 WARN  RequestContext dsRequest.execute() failed:  
java.lang.NullPointerException: null
    at com.isomorphic.sql.SQLSelectClause.addSQLForJoinedFields(SQLSelectClause.java:508) ~[isomorphic_sql.jar:?]
    at com.isomorphic.sql.SQLSelectClause.getSQLString(SQLSelectClause.java:429) ~[isomorphic_sql.jar:?]
    at com.isomorphic.sql.SQLSelectClause.getSQLString(SQLSelectClause.java:172) ~[isomorphic_sql.jar:?]
    at com.isomorphic.sql.SQLDataSource.getClausesContext(SQLDataSource.java:3205) ~[isomorphic_sql.jar:?]
    at com.isomorphic.sql.SQLDataSource.SQLExecute(SQLDataSource.java:1706) ~[isomorphic_sql.jar:?]
    at com.isomorphic.sql.SQLDataSource.processRequest(SQLDataSource.java:440) ~[isomorphic_sql.jar:?]
    at com.isomorphic.sql.SQLDataSource.executeFetch(SQLDataSource.java:385) ~[isomorphic_sql.jar:?]
    at com.isomorphic.datasource.DataSource.execute(DataSource.java:2456) ~[isomorphic_core_rpc.jar:?]
    at com.isomorphic.application.AppBase.executeDefaultDSOperation(AppBase.java:646) ~[isomorphic_core_rpc.jar:?]
    at com.isomorphic.application.AppBase.executeAppOperation(AppBase.java:547) ~[isomorphic_core_rpc.jar:?]
    at com.isomorphic.application.AppBase.execute(AppBase.java:490) ~[isomorphic_core_rpc.jar:?]
    at com.isomorphic.datasource.DSRequest.execute(DSRequest.java:2889) ~[isomorphic_core_rpc.jar:?]
    at com.isomorphic.servlet.IDACall.handleDSRequest(IDACall.java:230) [isomorphic_core_rpc.jar:?]

with the debugger I see that relatedDS.getTable() is null, and if I step into the getTable method actually this.table becomes correctly valued.

This happens on joined fields, inherited from a base dataSource. But it doesn't help if I repeat those fields in the inheriting dataSource.

[claudiobosticco]

About the strange error related to the joins: actually I don't need the joins for this summaryRow, so I've added an outputs attribute with the two fields actually necessary, which excludes all joins, so this is a workaround and also an optimization for me (remains the inefficiency of the multiple summary row fetches).

I don't know how I may help to find the root cause, but here's another little hint: the error happens only on the first (as served by tomcat) of those multiple fetches (and only if there are actually multiple fetches, so no error if in the queue there's only one request)

[claudiobosticco]

Hello, two questions:

1. Are you going to optimize the behavior of the first post (multiple fetches for the summary row when using queueing)?

2. Sometimes I succeed in replicating the problem from the 2nd/3rd post, doing multiple fetches on another operationBinding (without summaryFunctions), but with the joins. Are you interested in more debug on this issue, and ave you some hints about what I may try or analyze? Would my dataSources structure help you?

[Isomorphic]

Hello, two questions:

1. Are you going to optimize the behavior of the first post (multiple fetches for the summary row when using queueing)?

We've applied a fix back to SC 11.1p to avoid multiple summary row fetches due to data changes made against the master grid when sent as a queue. This is in the nightly builds dated 2019-05-23 and beyond.

2. Sometimes I succeed in replicating the problem from the 2nd/3rd post, doing multiple fetches on another operationBinding (without summaryFunctions), but with the joins. Are you interested in more debug on this issue, and ave you some hints about what I may try or analyze? Would my dataSources structure help you?

We've not seen that from your sample code above. If you have a way we can reproduce it, please provide it.

[claudiobosticco]

Hello, sorry for the late reply, I think I've found a test case to reproduce it, so I've just sent an email to your support address with a test case.

[Isomorphic]

We've received your test case. Is the authentication declared on the DataSources required to reproduce the problem or does it happen without that?

[claudiobosticco]

Hello, sorry for the delay. In the test case I've always used requiresAuthentication="true" as also in my application.
Some day ago I've retried to reproduce it but without success, with or without that setting :-(
But actually that random error in my application is still present.
So, for now I can't say if requiresAuthentication is required or not. I'll retry and let you know if I succed.