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

    Potential Bug in SQLDataSource

    SmartClient Version: v10.0p_2016-02-18/PowerEdition Deployment (built 2016-02-18)
    Isomorphic SmartClient/SmartGWT Framework (v10.0p_2016-02-18/PowerEdition Deployment (built 2016-02-18))

    Browser: Chrome

    I have a workaround for this so it is not urgent, and you may say it is expected behavior because we are misusing our datasource definitions, but thought I would pass it on anyway...

    Fields defined with the same nativeName attribute in a DataSOurce are causing a Class Cast Exception during insert/update.
    For reasons we don't need to go into, we have some fields that are defined in a datasource that have the same nativeName attribute. The duplicate field definition is marked canSave="false" because clearly we can't expect the framework to make a judgment of which value we'd like it to use to update the field when saving a record.

    The framework maintains a couple of maps for SQLDataSources to relate datasource field names to native table column names, and vice versa.

    When constructing the native2DSFieldMap, if there is more than one datasource field with the same nativeName attribute then the map entry ends up containing an array of strings instead of a string. E.g. ProductionDelivery datasource defines both _id_ and _deliveryId_ as having a nativeName="id". The resulting native2DSFieldMap entry for the native field name id looks like:

    This array structure causes a class cast exception in SQLDataSource.getFieldNameFromColumnName() line 390 during construction of an insert (and I assume update) statement:

    /*      */   public String getFieldNameFromColumnName(String columnName) {
    /*  390 */     return (String)native2DSFieldMap.get(columnName);
    /*      */   }
    There are various means of suppressing the duplicate field from appearing in the map, of which I believe using a customSelectExpression is a straightforward and reasonable way to do this, but I would think that perhaps canSave="false" should also suppress it. Or perhaps there just needs to be better error handling/reporting when the insert fails rather than a Class Cast Exception...?

    We would consider this invalid usage (even with the canSave=false) and would suggest instead using customSelectExpression, as you've already identified.

    We will take a look at cleanly reporting the error, however.


      Hi Isomorphic,

      you fixed a similar bug (nativeName pointing to an already existing field) back then in 5.1d.
      Also, you suggested having a duplicate nativeName as a solution to a design problem I had. I do only have one of those currently (=working), but will link this thread there if you say it is better to use customSelectExpression.

      Best regards


        if you use duplicated nativeNames there are cases where the system will definitely generate bad SQL (like "add" operations). For this reason, we can't support it as an official approach - customSelectExpression et al is the right approach if you want to use the same native column twice in a single SQL operation.

        Sorry about the confusion in the other thread - we meant only to show appreciation of a neat hack, not to endorse the approach as valid.


          OK, I'll change all duplicate nativeName to customSelectExpression.

          Users finding this thread via search: This thread is related.

          Best regards