SQLDataSource merge fields with nativeName specified

[bbruyn]

Add a simple datasource to the BuiltInDS example to reproduce the following.

Seems that when I have some datasource that might look like

<DataSource ID="STATE" serverType="sql" tableName="STATE">
    <fields>
        <field name="STATE_UK" type="number"/>
	<!-- and so on -->
    </fields>
</DataSource>

And I want to autoDeriveSchema but also rename some column(s) via nativeName (http://www.smartclient.com/smartgwte...tml#nativeName)

<DataSource ID="state" serverType="sql" tableName="state" autoDeriveSchema="true">
    <fields>
        <field name="stateId" nativeName="STATE_UK"/>
    </fields>
</DataSource>

SmartGWT issues the following SQL:

SELECT [b]STATE.STATE_UK[/b], 
  STATE.DESCRIPTION, 
  [b]STATE.STATE_UK AS stateId[/b], 
  STATE.STATE_CODE,
  STATE.REGION_UK, 
  STATE.COUNTRY_UK 
FROM STATE WHERE ('1'='1')

Instead of merging the definitions up and selecting the column once. What this does, of course, is cause components with no field component-level overrides (e.g.,'pattern reuse' forms, default filterbuilders, etc.) to carry that definition twice - once with the name as defined on the underlying table (state_uk) and once with the alias (stateId).

Bug?

SmartGWT 2.5 nightly eval (2/23 build)

[Isomorphic]

Interesting edge case, but not necessarily a bug. What's happening is that autoDeriveSchema essentially operates through DataSource inheritsFrom (as doc'd), so, your implicit parent DataSource has a field "STATE_UK" which your new field "stateId" *does not override* because it has a different name.

You can get rid of the effects of the parent field by re-declaring it inapplicable:true and customSQL="true", in addition to your separate declaration of a new field stateId. However in this case you are effectively declaring a new field, so you will need to declare type and anything else that autoDeriveSchema might have derived from SQL schema for this field.

[bbruyn]

Fair enough, but I can't think of a case where I'd want to preserve the parent definition (reads javadoc again...)

Anyway, just thought I'd point it out. It isn't terribly important. I'll just keep my awesomely bad column names. :-)

Thanks for all your help so far, by the way. Proof of concept has so far been well-received.