omar wrote:
FRANS.. just for the sake of sake of knowing:
1- is it possible to explain why the architecture of LLBL cannot support UNION and UNION ALL
The reason is simple: say you want to fetch a set of entities. To specify that fetch, you'd probably call FetchEntityCollection by specifying some parameters. The resultset is defined by the list of fields of the entity type to fetch, and the parameters are to limit the resultset, to sort it.
When UNION should be supported, you should be able to specify 2 or more FetchEntityCollection calls together which should be migrated into 1 query, as every call results into a full query and UNION is actually just a way to chain multiple SQL queries which can be unrelated, together.
If there would be a query object in the API, where the query object would be the parameter of the FetchEntityCollection method (and other fetch methods), it would be rather easy to support UNION, as the Query object would get an option to get an additional query object or a master query object would be introduced which would simply chain containing query objects together.
There are other reasons why it's not supported: inheritance and union is very complex and not really doable, as union suggests that you chain queries together which are not always related, though with inheritance the resulting query isn't known up front (it depends on the # of subtypes for example).
2- Any plans to add this support in an upcoming version (hopeful for this to go the same way as Derived Tables did)
Well, definitely not for entity types. We could look into supporting UNION for sets of data (projections) which are then usable for either projections or in filters (so in that light it would be useful).
I'll add it to the todo list for v3, but it's not 100% sure this will be in v3.0. (as v3.0 already has a huge truckload of changes in the designer and also in the runtime (value types for example) so it depends if there is enough time)