<groupBy> clause in datasources no longer working in 12.1?

[user316]

Hi,

I am getting errors when trying to load datasources in version 12.1d that are using <groupBy> clauses inside of the operation bindings for fetches. This previously worked in 12.0. Do you know what could be causing this? Looking at the Chome debugger, it looks like the generated field names in the javascript code from the datasource .ds.xml file are missing quotes and that's the issue within the framework?

Changing <groupBy> to <groupClause> in all the datasources isn't a fix since it seems the behavior between the two is different - I guess <groupBy> allowed custom fields to be put in that aren't necessarily in the executed SQL.

My version of SmartGWT:

SNAPSHOT_v12.1d_2019-05-16/PowerEdition Deployment (built 2019-05-16)

Uncaught ReferenceError: PK_Project is not defined
at DataSourceLoader?dataSource=ChipSTA,ChipSTA_Project_Instances,ChipSTA_Project_Corners_Modes,ChipSTA_ChipSummary,ChipSTA_WaiverFiles,ChipSTA_ChipDetails,ChipSTA_ChipDetails_Filters,ChipSTA_ChipDRVDetails,ChipSTA_ChipFloorPlan,ChipSTA_DRV_PVT_Sum,ISO_UIServerCriteria,Email,Users,ChipSTA_Run_PVT_Mode:2

My operation binding looks like this:

<operationBinding operationType="fetch" operationId="fetchChips">

<groupBy>PK_Project,ProjName_Revision,VM_Project,FK_srcProject, HasRunData, Title</groupBy>
<orderClause>VM_Project ASC, ProjName_Revision</orderClause>
</operationBinding>

Example of issue in Chrome debugger (see area highlighted in red in screenshot)

[Isomorphic]

So that's technically not a correct format for groupBy - the standard XML format for Array fields is like this:

<groupBy>
    <field>foo</field>  <!-- doesn't matter what you name the inner tag here -->
    <field>bar</field> 
</groupBy>

However there are several places where a shorthand format like you used *is* allowed, and this was working before so we'll get it fixed.

[user316]

Ok, thank you. Please keep me updated on when this fix is released and available in the latest version of 12.1p.

Also in an example from the documentation, I don't see the customerName field wrapped inside of a <field></field>:

https://www.smartclient.com/smartgwt...Summaries.html

<groupBy>customerName</groupBy>

[Isomorphic]

Yes, for a singular item for an Array field, that format is allowed.

[Isomorphic]

We're not reproducing any crashes in our own testing. Can you provide a complete, standalone repro case or modifications to a Showcase sample that will show the issue? For a standalone case, include the root HTML page and datasource definition.

[user316]

Hello, I also could not produce the issue in the Showcase sample. However, it still occurs in a very stripped down version of our app. Can you see if you can reproduce it from this case? See attached.

I also made sure no custom servlets are being used that could be affecting the DataSourceLoader. I'm quite confused as to why the problem happens in our app but not in the showcase sample (used builtinds) when I tested it.

[Isomorphic]

We haven't tried this sample code yet, but the likely cause is that you have named a DataSource something very fundamental that interferes with normal XML processing, such as "operationBinding" or some other tag name that appears in .ds.xml files. This would mean your sample code won't reproduce it for us, so just try removing all DataSources other than the one under test and see if that corrects the issue.

[user316]

edit: still investigating.

[user316]

I figured out the problem - in our ant deploy script, it was copying the libs from version 12.0 instead of 12.1. So there was a mismatch between the client (which was using 12.1) and server-side code (which was using 12.0).

[user316]

There is another issue regarding our datasources. We have our own custom datasource called "Project". In 12.1, it seems to be instead loading in an internal SmartGWT datasource by the same name, also "Project". I was able to work around this issue by renaming our Project datasource to something else, but is there a fix that has less impact to us, so we don't have to modify all the source code files that refer to the datasource by "Project"? Is there a way to specify the ordering that it finds datasources, so it loads in our custom Project.ds.xml first?

[Isomorphic]

Project is a Framework schema. Perhaps you want to run in portal mode?

[Isomorphic]

Regarding isomorphic_core_rpc.jar (the post you edited away), just note that without this .jar, the server-side system won't function at all - nothing will work. So rather than just copying the wrong version, that result suggested duplicate .jars were around, so you might want to double-check on that. *Just* having mismatched client and server .jars probably doesn't explain the groupBy issues, but mixed versions of server .jars in the same deployment would.

Regarding the "Project" DataSource - note that you will only expose yourself to such possible conflicts if you start your DataSource IDs with a capital letter, so we would highly recommend changing the name.

A terrible short-term hack would be place your Project.ds.xml in a directory on its own, and put that directory in the framework DataSource search path first, by redefining framework.datasources in your server.properties file so that it is:

framework.datasources: path/to/dir/with/your/project/datasource, $isomorphicDir/system/schema

[user316]

I'm not sure what our plans are right now as to whether we will use the short-term hack or not, but I am not seeing "framework.datasources" anywhere in my server.properties. Does that mean it is using some sort of hidden default definition to load in the framework datasources? I only see "project.datasources", which doesn't appear to be including the framework datasources such as the framework version of Project.ds.xml at all.

*Just* having mismatched client and server .jars probably doesn't explain the groupBy issues

I am fairly sure that we only had mismatched client and server .jar versions, specifically with the isomorphic_core_rpc.jar.

[Isomorphic]

That's correct - this is a hack because it would be using internal properties.

Again, nothing would have worked, or even started up, without isomorphic_core_rpc.jar. Your results clearly indicate that .jar was present, although it may have been an older version. So you should look closely at your deployment scripts to understand what was going on.

[user316]

That's correct - this is a hack because it would be using internal properties.

Again, nothing would have worked, or even started up, without isomorphic_core_rpc.jar. Your results clearly indicate that .jar was present, although it may have been an older version. So you should look closely at your deployment scripts to understand what was going on.

Yes, it was a mistake in not updating the deployment script. I didn't realize that when running through Eclipse, the server-side uses the libraries from the WEB-INF folder and not from the Eclipse classpath.