public interface UnionDataSource
SQL DataSources, and it uses the SQL UNION keyword to achieve this.
UnionDataSource is useful when you need a unified view of data entities that, for whatever reason, you ordinarily keep separate. A plausible example is Customers and Suppliers; those are two distinct entities, and would typically be implmented as separate database tables or Hibernate persistent classes, or whatever. This makes sense: there are lots of things you want to know about a Customer that are not relevant for a Supplier, and vice versa. In most ways, these are not similar things.
However, from a Customs point of view, Customers and Suppliers are similar - they are both Trading Partners. As mentioned above, you probably store lots of things about Customers that you don't store about Suppliers and vice versa, but there will be a set of fields common to both - name, address, country, and financial details like total amount sold or purchased this year. You can use UnionDataSource to provide a "Trading Partners" view of this data.
If your member dataSources are very similar, unionDataSource can work in an auto-config mode where all you specify is the list of member dataSource in the unionDataSource's
unionOf property, and we derive a
set of common fields amongst the
members where the names and data types match (there is flexibility in this auto-derivation
process - see
You can trim this by specifying the list of fields you want to union (again, assuming they
have the same name in each member dataSource) using the
unionFields property. 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"/>Performance note