Announcement

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

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

    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:
    Code:
    <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)


    Click image for larger version  Name:	groupByissue.png Views:	1 Size:	34.1 KB ID:	257829
    Last edited by user316; 20th May 2019, 06:51.

  • Isomorphic
    replied
    Ah, ok, there is in fact a bug in the server-side processing in the dev release. This will be fixed in tomorrow's build (Jun 7)

    Leave a comment:


  • tece321
    replied
    I am of the opinion that any datasource names or ids distributed by Isomorphic should have a very small likelihood of clashing with customer normal usage. While there appears to be a way to avoid client side ID clashes, you have not offered an equivalent for server side clashes.

    There shouldn't be a datasource with a common ID of "Project" in the distribution. There must be many customers using that ID. It is peculiar that this did not become apparent before 12.1 releases. Nevertheless if I understand the problem I think Isomorphic should ensure that any distributed datasource should have a unique ID, client or server side.

    Leave a comment:


  • user316
    replied
    So we are wondering why we are seeing this problem only now? What could have changed in the framework version that would cause this? I looked at earlier SmartGWT versions and noticed that the Isomorphic Project.ds.xml still existed there. Did the load order of datasources change? If I simply revert back to 12.0 the problem goes away.

    Leave a comment:


  • user316
    replied
    Originally posted by Isomorphic View Post
    Yes, that approach will only work for client-side collisions, if you're experiencing that.
    Ah, ok. It's a server-side fetch which isn't working.

    Leave a comment:


  • user316
    replied
    The HTML file is here if you'd like to take a look: ChipSTA.html

    Leave a comment:


  • Isomorphic
    replied
    Yes, that approach will only work for client-side collisions, if you're experiencing that.

    Leave a comment:


  • user316
    replied
    I tried setting "window.isc_useSimpleNames = false;" inside of a <script> </script> tag in my header before the SmartGWT libraries are loaded, but it didn't fix the issue or make any difference. The only way I can seem to fix it is by renaming the internal SmartGWT Project.ds.xml or otherwise renaming our datasource.

    Last edited by user316; 4th Jun 2019, 09:11.

    Leave a comment:


  • user316
    replied
    Yes, I saw that, but perhaps it's better if Isomorphic changes all the internal datasources to Isomorphic_*.ds.xml - for example, Isomorphic_Project.ds.xml? That way it would greatly reduce the likelihood of any conflicts?

    edit: ok, I see what you mean, let me try the portal mode setting
    Last edited by user316; 3rd Jun 2019, 11:58.

    Leave a comment:


  • Isomorphic
    replied
    Did you see post #11 above?

    Leave a comment:


  • user316
    replied
    Just wanted to ask, is there any chance you could rename the internal SmartGWT "Project" datasource to something else? Isn't it likely that naming it something generic such as "Project" could conflict with a lot of apps that use SmartGWT?

    Leave a comment:


  • user316
    replied
    Originally posted by Isomorphic View Post
    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.

    Leave a comment:


  • Isomorphic
    replied
    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.

    Leave a comment:


  • user316
    replied
    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.
    Last edited by user316; 31st May 2019, 05:46.

    Leave a comment:


  • Isomorphic
    replied
    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

    Leave a comment:

Working...
X