com.smartgwt.client.docs

Interface UnionDataSource

public interface UnionDataSource

Union DataSources

The UnionDataSource assimilates records from multiple member dataSources, matching fields by name and data type, or by explicit configuration. Different types of member dataSource are allowed, so you can union SQL data with Hibernate data and generic data from a legacy system, for example. For efficiency, Smart GWT will use the SQL UNION keyword to achieve the data union for any members dataSources that are SQL DataSources; data from any non-SQL members is combined in Java code as a post-process.

Like other dataSource types, unionDataSources can filter, sort and page their bonded data sets, and other dataSource features like declarative security and included fields work as you would expect. However, Server Summaries and grouping do not currently work with UnionDS.

Example usage
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.

Configuration
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 defaultUnionFieldsStrategy). 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
Ordering and paging with a UnionDataSource only makes sense when applied to the bonded dataset; in order to ensure that we can sort and page the overall dataset correctly, we must fetch every matching record from each member dataSource. For this reason, you should not rely on the paging feature to keep the number of records in the working dataset small; always provide criteria for that purpose. This is a good practice, and one we recommend for any type of dataSource, but it is particularly important with unionDataSource, to avoid situations where we have to fetch thousands or millions of rows from multiple member dataSources, in order to find out which of those rows are in positions 100 to 150 with the current sort settings.