Bugs related to the critieria builder and componentXML

[fatzopilot]

Hi,

(1) I've defined a ListGrid in a componentXML Screen (which works fine) and am now trying to set the initial criteria for it.
E.g. like so:

<isomorphicXML xmlns:fmt="WEB-INF/">
	<DataSource>
	    <loadID>SomeBean</loadID>
	</DataSource>
	
	<NewCustomGrid dataSource="ref:SomeBean" autoFetchData="true" ID="someBeanListGrid" autoDraw="false">
	    <fields>
		 <ListGridField name="startTime" title="Start Time"/>
	       ...
	    </fields>
	    <listEndEditAction>next</listEndEditAction>
	    <showFilterEditor>true</showFilterEditor>
	    <canEdit>true</canEdit>
	    <canRemoveRecords>true</canRemoveRecords>
		 <initialCriteria><Criterion>
	         <fieldName>startTime</fieldName><operator>greaterThan</operator><value>13533696000</value>
	    </Criterion></initialCriteria>
	</NewCustomGrid>
</isomorphicXML>

On the server I get the following:

criteria: {fieldName:"startTime",operator:"greaterThan",value:"13533696000"}	values: {fieldName:"startTime",operator:"greaterThan",value:"13533696000"}
=== 2013-05-20 15:26:57,437 [c-11] DEBUG HibernateTransaction - [builtinApplication.ref:SomeBean_fetch] Started new transaction "10778264"
=== 2013-05-20 15:26:57,438 [c-11] WARN  HibernateDataSource - [builtinApplication.ref:SomeBean_fetch] Trying to compare date type field 'startTime' with java.lang.String type value in criterion 'greaterThan'
=== 2013-05-20 15:26:57,438 [c-11] INFO  HibernateDataSource - [builtinApplication.ref:SomeBean_fetch] Query string: select _SomeBean from com.aCompany.SomeBean _SomeBean  where 1=2 and _SomeBean.startTime is not null
Hibernate: select count(*) as col_0_0_ from SomeBean SomeBean0_ where 1=2 and (SomeBean0_.start_time is not null)

This seems like a bug to me since 1=2 is always false and consequently nothing is returned.

(2) A related bug:
When I add another criteria in a server side DMI, e.g.

long[] clientIds = new clientIds[]{41L};
Map criteria1 = dsRequest.getCriteria();
System.out.println(criteria1); //gives {fieldName=startTime, operator=greaterThan, value=13533696000}
dsRequest.addToCriteria("clientId", "inSet", clientIds);
Map criteria2 = dsRequest.getCriteria();
System.out.println(criteria2); //gives {criteria=[{value=startTime, fieldName=fieldName, operator=contains}, {value=greaterThan, fieldName=operator, operator=contains}, {value=13533696000, fieldName=value, operator=contains}, {value=[41], fieldName=clientId, operator=inSet}], operator=and, _constructor=AdvancedCriteria}

the previous critiera gets corrupted and consequently the following warning is logged (and the criteria is not applied):

=== 2013-05-20 15:53:07,681 [ec-7] WARN  HibernateDataSource - [builtinApplication.ref:SomeBean_fetch] Field name: 'fieldName' specified in criteria is not defined in data source. Skipping.
=== 2013-05-20 15:53:07,681 [ec-7] WARN  HibernateDataSource - [builtinApplication.ref:SomeBean_fetch] Field name: 'operator' specified in criteria is not defined in data source. Skipping.
=== 2013-05-20 15:53:07,681 [ec-7] WARN  HibernateDataSource - [builtinApplication.ref:SomeBean_fetch] Field name: 'value' specified in criteria is not defined in data source. Skipping.

(3) A related question:
What I would actually like to do here is to set a criteria date 2 weeks in the past from now on. Is this doable using just componentXML? In plain Java, I'd just do something like long value = (new Date().getTime() - 2WeeksMsInLong) but how to do this inside a componentXML?

SmartClient Version: v8.3p_2013-05-16/PowerEdition Deployment (built 2013-05-16)

Thanks,
fatzopilot

[Isomorphic]

You're getting the 1=2 in the where clause because it's considering invalid to pass a String as criteria for a "data" field. Instead, specify xsi:type="date" on the <value> element and provide the date in XML Schema format (same as for RestDataSource, if you need a sample).

[fatzopilot]

Thanks,

that help fixing the issue with 1=2.

Cheers,
fatzopilot

[fatzopilot]

Hi,

There are still some open issues in this post that give me headaches right now:

I've still have no idea on how to combine criteria in a DMI without them getting corrupted (like described in 2).

The new Issue (4) is related to (1) but maybe even by (2):

I'd like to combine criteria in a fetch operations, one is from a DS' operation binding, i.e. like so:

...
<operationBindings> 
        <operationBinding operationType="fetch"> 
      		<criteria fieldName="deleted" value="false"/>
                       <serverObject className="myCompany.MyDMI"/>
        </operationBinding>
...
</operationBindings> 
...

and the other criteria is the same as in example (2), i.e. add a client property criteria dynamically, which this time yields:

=== 2013-08-20 16:06:19,837 [ec-4] INFO  HibernateDataSource - [builtinApplication.ref:someBean_fetch] Performing fetch operation with
	criteria: {criteria:[{value:"false",fieldName:"deleted",operator:"contains"},{value:[41,38,15,14,18,27],fieldName:"client",operator:"inSet"}],operator:"and",_constructor:"AdvancedCriteria"}	values: {criteria:[{value:"false",fieldName:"deleted",operator:"contains"},{value:[41,38,15,14,18,27],fieldName:"client",operator:"inSet"}],operator:"and",_constructor:"AdvancedCriteria"}
=== 2013-08-20 16:06:19,838 [ec-4] DEBUG HibernateTransaction - [builtinApplication.ref:someBean_fetch] Started new transaction "114956310"
=== 2013-08-20 16:06:19,839 [ec-4] WARN  HibernateDataSource - [builtinApplication.ref:someBean_fetch] Found criterion 'contains' with field 'deleted' that is neither instance of String nor instance of Character nor instance of Number.
Returning predicate '1=2' (always false).

Without the added client property criteria, there is no problem.
I tried to fix this using the approach you described for componentXML (1), i.e.

<operationBinding operationType="fetch"> 
      		<criteria fieldName="deleted" value="false"/>
      		<criteria>
	      		<Criterion>
		         	<fieldName>deleted</fieldName><operator>equals</operator><value xsi:type="xsd:boolean">false</value>
		    	</Criterion>
      		</criteria>
      		<serverObject className="myCompany.MyDMI"/>
  		</operationBinding>

but then get

java.lang.ClassCastException: java.lang.Boolean cannot be cast to java.lang.String
	at com.isomorphic.rpc.RPCManager.applyEarlierResponseValues(RPCManager.java:2272)
	at com.isomorphic.datasource.DSRequest.execute(DSRequest.java:2011)
	at com.isomorphic.servlet.IDACall.handleDSRequest(IDACall.java:216)
	at com.isomorphic.servlet.IDACall.processRPCTransaction(IDACall.java:173)
	at com.isomorphic.servlet.IDACall.processRequest(IDACall.java:138)
	at com.isomorphic.servlet.IDACall.doPost(IDACall.java:74)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:647)
	at com.isomorphic.servlet.BaseServlet.service(BaseServlet.java:152)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)

Changing the type to xsi:type="xsd:string" yields the original log message.

How to get a properly combined and working criteria set here?

In addition Question (3) is still open: Is this possible in a componentXML?

Thanks,
fatzopilot

[Isomorphic]

On 4), <criteria><Criterion> is not correct in an operationBinding. Just use a series of <criteria> tags with fieldName, operator and value specified.

On 2), can you show a way to reproduce this by modifying a sample?

On 3), you could do this by specifying the value of a Criterion as a relativeDateString

[fatzopilot]

OK,

so here is an example based on the HibernateSpringDMI example: https://dl.dropboxusercontent.com/u/18305668/spring-hibernate-dmi.zip

The criteria object is populated in two ways,
* first, by an initialCriteria statement in the ListGrid componentXML (defined in One.ui.xml)
* second, in the DMI itself.
After adding the DMI criteria, the criteria object looks strange and doesn't work with the usual Smartgwt server fetch operation. The latter cannot be demonstrated in this example as it doesn't use the SGWT server fetch method (I was unable to get the other examples work with DMI operation bindings...), but behaves like described in (2). Both single critiera work if not combined.

The problem seems to be the initialCritiera in the ListGrid. If the critiera is instead populated in the operation bindings block in the datasource, the critieria object does not get corrupted in the DMI when another criteria is added.

Thanks,
fatzopilot

[fatzopilot]

On 3), you could do this by specifying the value of a Criterion as a relativeDateString

I tried e.g. this in a ListGrid definition

	     <initialCriteria><Criterion>
	         <fieldName>startTime</fieldName><operator>greaterThan</operator><value xsi:type="xsd:date">-2w[-0D]</value>
	    </Criterion></initialCriteria>

and got this warning

=== 2013-10-06 13:52:05,205 [ec-7] WARN  Validation - Validation errors validating a 'ListGrid':
{
    "/ListGrid[@ID=Scheduler_33]/initialCriteria/Criterion":{
        recordPath:"/ListGrid[@ID=Scheduler_33]/initialCriteria/Criterion",
        value:{
            errorMessage:"Must be a date."
        }
    }
}
=== 2013-10-06 13:52:05,206 [ec-7] WARN  Validation - Validation errors validating a 'isomorphicXML':
{
    "/ListGrid[@ID=Scheduler_33]/initialCriteria/Criterion":{
        recordPath:"/ListGrid[@ID=Scheduler_33]/initialCriteria/Criterion",
        value:{
            errorMessage:"Must be a date."
        }
    }
}

and then

Trying to compare date type field 'startTime' with java.lang.String type value in criterion 'greaterThan'

and again the "1=2 issue" (see previous posts).

If the valueType is ommitted, the validation warning goes away but the rest is the same.

Is there a special xsd value type for this purpose? I haven't found something useful here: http://infohost.nmt.edu/tcc/help/pubs/rnc/xsd.html. I tried something like 'xsd:relativeDate' but to no avail.

Thanks,
fatzopilot

SmartClient Version: v8.3p_2013-09-25/PowerEdition Deployment (built 2013-09-25)

[Isomorphic]

A RelativeDateString is not a Date so setting xsd:date is wrong.

There should be no need to set xsd:RelativeDateString or anything like that since the value is already a String.

However the server does not currently have code for interpreting RelativeDateString - this is always done client-side, and the server receives the value as a specific Date.

Regarding the criteria combination problem - it looks like you tried to provide a test case as a .zip. Don't do this, just provide .java files. If your test case is based on a sample, just tell us what sample and show the changed files.