SQL Datasource update operation triggers initial fetch

[mpretorian]

Hi,

I'm using smartgwt-power-3.1-p20130712.

I have a datasource with
- a field of type "creator"
- 2 fetch operations (one without operation id, and one with operation id = fetchById)
- one update operation that has cacheSyncOperation="fetchById"

When the client calls some form.saveData that triggers an update on the server, first the fetch without operation id is called and then the update is executed.

1) Is that fetch really needed? I don't have any field security specification and my authorization is not based on "creator" concepts. Could that fetch be removed? Or I should not use the "creator" type?

2) Why is called the fetch without operation id and not at least the one specified as cacheSyncOperation?

Regards,
Mihnea

[Isomorphic]

We can't speculate from just this information. Try providing the required basics, like the server log for the request and the DataSource definition (.ds.xml file).

[mpretorian]

Here is the datasource update server request:

=== 2013-07-22 18:29:54,320 [ec-4] DEBUG RPCManager - Request #1 (DSRequest) payload: {
    criteria:{
        id:"5B826326EFA511E2A4170013729DE20F"
    },
    values:{
        phone:"+1(1)11111111111111112",
        ...
        id:"5B826326EFA511E2A4170013729DE20F",        
    },
    operationConfig:{
        dataSource:"mseContacts",
        operationType:"update"
    },
    componentId:"isc_CustomerContactForm_Edit_contact_Form_5",
    appID:"builtinApplication",
    operation:"mseContacts_update",
    oldValues:{
        phone:"+1(1)11111111111111112",
        ...
        id:"5B826326EFA511E2A4170013729DE20F",
    }
}

Here is the stack trace of the update request that called the fetch operation (see DeclarativeSecurity.performFieldLevelDSRequestChecks that makes the fetch):

Daemon Thread ["http-bio-8080"-exec-4] (Suspended (breakpoint at line 65 in ContactFetchDMI))	
	owns: SocketWrapper<E>  (id=140)	
	ContactFetchDMI.fetch(DSRequest) line: 65	
	GeneratedMethodAccessor161.invoke(Object, Object[]) line: not available	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
	Method.invoke(Object, Object...) line: 597	
	AopUtils.invokeJoinpointUsingReflection(Object, Method, Object[]) line: 318	
	ReflectiveMethodInvocation.invokeJoinpoint() line: 183	
	ReflectiveMethodInvocation.proceed() line: 150	
	MethodSecurityInterceptor.invoke(MethodInvocation) line: 61	
	ReflectiveMethodInvocation.proceed() line: 172	
	TransactionInterceptor.invoke(MethodInvocation) line: 110	
	ReflectiveMethodInvocation.proceed() line: 172	
	MethodBeforeAdviceInterceptor.invoke(MethodInvocation) line: 50	
	ReflectiveMethodInvocation.proceed() line: 172	
	TransactionInterceptor.invoke(MethodInvocation) line: 110	
	ReflectiveMethodInvocation.proceed() line: 172	
	ExposeInvocationInterceptor.invoke(MethodInvocation) line: 90	
	ReflectiveMethodInvocation.proceed() line: 172	
	JdkDynamicAopProxy.invoke(Object, Method, Object[]) line: 202	
	$Proxy114.fetch(DSRequest) line: not available	
	GeneratedMethodAccessor159.invoke(Object, Object[]) line: not available	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
	Method.invoke(Object, Object...) line: 597	
	Reflection.adaptArgsAndInvoke(Object, Method, ReflectionArgument[], ReflectionArgument[], DataSource, DSRequest) line: 972	
	DataSourceDMI.execute() line: 416	
	DataSourceDMI.execute(DSRequest, RPCManager, RequestContext) line: 64	
	DSRequest.execute() line: 2034	
	DeclarativeSecurity.performFieldLevelDSRequestChecks(DSRequest) line: 481	
	DSRequest.execute() line: 1977	
	IDACall<RT>.handleDSRequest(DSRequest, RPCManager, RequestContext) line: 97	
	IDACall<RT>(IDACall).processRPCTransaction(RPCManager, RequestContext) line: 173	
	IDACall<RT>(IDACall).processRequest(HttpServletRequest, HttpServletResponse) line: 138	
	IDACall<RT>(IDACall).doPost(HttpServletRequest, HttpServletResponse) line: 74	
	IDACall<RT>(HttpServlet).service(HttpServletRequest, HttpServletResponse) line: 641	
	IDACall<RT>(BaseServlet).service(HttpServletRequest, HttpServletResponse) line: 152	
	IDACall<RT>(HttpServlet).service(ServletRequest, ServletResponse) line: 722

Here is the datasource definition:

<?xml version="1.0" encoding="UTF-8" ?>
<DataSource ID="mseContacts" serverType="sql" dbName="xxx" tableName="TTT" autoJoinTransactions="true">
    <fields>
        <field name="id" type="text" hidden="true" escapeHTML="true" nativeName="ID" primaryKey="true" />
 ...        
        <field name="creationDate" type="creatorTimestamp" operator="equals" nativeName="xxx" />
        <field name="insertedBy" type="creator" operator="equals" nativeName="xxx" />
        <field name="lastUpdateOn" type="modifierTimestamp" operator="equals"  nativeName="xxx" />
        <field name="lastUpdateBy" type="modifier"  operator="equals" nativeName="xxx" /> 
...
    </fields>

    <operationBindings>
    
	<operationBinding operationType="fetch" operationId="fetchContactById" sqlUsePagingHint="false" serverMethod="fetch" skipRowCount="true" >
		<serverObject lookupStyle="spring" bean="contactFetchByIdDMI" />
		<whereClause>TTT.ID = $id</whereClause>
	</operationBinding>
    
    
	<operationBinding operationType="fetch" sqlUsePagingHint="false" serverMethod="fetch" skipRowCount="true" >
		<serverObject lookupStyle="spring" bean="contactFetchDMI" />
		<selectClause>
...    	</selectClause>
		<whereClause>
...		
		</whereClause>
		<orderClause>
...		</orderClause>	
	</operationBinding>	
	<operationBinding operationType="add" serverMethod="add" cacheSyncOperation="fetchContactById">
		<serverObject lookupStyle="spring" bean="contactAddDMI"/>
	</operationBinding>
	<operationBinding operationType="remove" requires="false">
	</operationBinding>
	<operationBinding operationType="update" serverMethod="update" cacheSyncOperation="fetchContactById">
		<serverObject lookupStyle="spring" bean="contactUpdateDMI"/>
	</operationBinding>
	
	</operationBindings>
</DataSource>

[Isomorphic]

It looks like you have enabled the creatorOverrides behavior discussed in the Declarative Security docs.

In this case, we need to find out the creator of the record in order to understand if the creatorOverrides rule applies.

[mpretorian]

I wanted only to use the "creator" field type to fill in a special INSERTED_BY column.
But I don't need to apply any creatorOverrides rule.

How can I disable those rules?
Should I give up using the "creator" type and fill in the data myself?
I think that such rules should not be enabled by only using the "creator" type.

[Isomorphic]

Sorry, we don't follow.

You have enabled the creatorOverrides setting. In order for the functionality of creatorOverrides to work, it must do this initial fetch.

If you don't want to use creatorOverrides, just turn it off.

[mpretorian]

How to switch it off?
I didn't switch it on on purpose.
I only defined a field like here:
<field name="insertedBy" type="creator"/>

To switch it off means to not user the type "creator" in my fields definitions?

[mpretorian]

Any news on this issue?

[Isomorphic]

We've tracked this to a case where the creatorOverrides behavior is kicking in even though it is not configured as enabled. Should be fixed later this week.

[mpretorian]

Thank you. Please post the version with the fix when is ready.

[mpretorian]

Any news on this issue?

[Isomorphic]

A fix has been committed today. It will appear in nightly builds of 8.3p and later as of tomorrow, August 7.

[mpretorian]

Thanks. Works with the version from 2013/08/07.