13.1d new sample unionDataSource broken

[Blama]

Hi Isomorphic,

I just noticed that the new unionDataSource sample (SNAPSHOT_v13.1d_2022-10-09) does not show any data, even though the request in the Developer Console shows transferred data.
The data received has more fields than expected, though and also has the field names in all-capital letters (unexpected).

Best regards
Blama

[Blama]

Hi Isomorphic,

as a FYI, this one is still open (SNAPSHOT_v13.1d_2022-11-23).

Best regards
Blama

[Isomorphic]

Thanks for the report. This was a problem with the new UnionDataSource feature, specific to the HSQLDB database. It is now corrected.

[Blama]

Hi Isomorphic,

thanks, I can see data in the sample now, again (SNAPSHOT_v13.1d_2022-12-02).
The data in the RPC Tab of the Developer Console looks like this, though:

data:[
        {
            Email:"afreel@server.com",
            name:"Abe Freel",
            employeeId:207,
            Job:"Stores Worker",
            agencyName:null
        },...

The staff-DataSource has only these fields:

<DataSource isSampleDS="true"
    ID="staff"
    serverType="union"
    unionOf="employees,subcontractors,agency_workers"
>
    <fields>
        <field name="name" title="Name" unionOf="employees.Name,subcontractors.fullName,agency_workers.name"/>
        <field name="employeeId" title="Employee ID" unionOf="employees.EmployeeId,agency_workers.agencyRef"/>
        <field name="agencyName" unionOf="agency_workers.agency"/>
    </fields>
</DataSource>

I don't think the server should send values for Job and Email, as they are not defined in the DataSource.

Best regards
Blama

[Isomorphic]

Hi Blama,

UnionDataSource has some quite sophisticated, non-obvious behavior where field derivation is concerned, and the behavior you describe here is by design. The fields of a unionDS are inherited from the member dataSources, guided by either the "unionFields" setting, or by auto-derivation rules in its absence; the <fields> declaration is only intended for specifying override information, similar to a DataSource that specifies inheritsFrom. To quote from the docs (https://smartclient.com/smartclient-...nionDataSource):

You can also refine the auto-derived configuration by specifying field definitions in the unionDataSource, using field-level unionOf definitions to explicitly declare which member fields should be unioned. You can also use unionDataSource field definitions to optionally rename the unioned field, and do more mundane things, like change the title. Eg,

<field name="tradingPartnerId" unionOf="customerDS.custId,vendorDS.vendorCode" title="Partner ID"/>

The Job and Email fields are being included here because the "Staff" dataSource does not specify a "unionFields" property, so the auto-config kicks in. The defaultUnionFieldsStrategy is also not specified, so that defaults to "matching", and again from the docs (https://smartclient.com/smartclient-...FieldsStrategy):

"matching"

Create a unioned field where at least two of the member dataSources have a field with the same name and data type. Any member dataSources that do not have the field will contribute a null value for that field in the unioned dataset

The way to achieve what you are expecting with UnionDataSource would be to specify unionFields="name,employeeId,agencyName"; alternatively, an "outputs" setting on an operationBinding would have the same effect.

Thanks,
Isomorphic Software Support

[Blama]

Hi Isomorphic,

thanks for the insight. This all makes sense to me.
I do think that a few additions of what you just explained to the docs here will help, and one thing it not clear to me here.

You suggest in #5 unionFields="name,employeeId,agencyName", but the unionFields docs say:

Note, this setting is only useful for fields that are named the same on the member dataSources.

If this does work, then your last comment in #5

The way to achieve what you are expecting with UnionDataSource would be to specify unionFields="name,employeeId,agencyName"; alternatively, an "outputs" setting on an operationBinding would have the same effect.

would be great in the defaultUnionFieldsStrategy and/or unionFields docs.
If it does not work, then just the part with the outputs.

Best regards
Blama

[Isomorphic]

Yes, the documentation is slightly misleading there. It should say something like "this setting is only useful by itself for fields that are named the same on the member dataSources", because what it does is cause the list of fields to be those that are named in the "unionFields" string and:

1. Exist on all member dataSources, with the same data type in each case, or
2. Are explicitly declared in the UnionDataSource (perhaps, but not necessarily, with field-level unionOf declarations that do more nuanced unioning)

We will look at making some additions to the docs to make this clearer