When you released FULL linq support, I did not see you skipped 'union' support. Of course, I need it.

I am doing two linq queries and both use

select new SomeType {blah}

and SomeType is the same for both.

I then try to concat the results. There should be no reason why you cannot support this scenario. Of course if I am trying to union to select Entity queries or something, I can imagine the complexity....however if I project onto a new class, it should be supportable???

Please advise.

Union isn't supported because the execution pipeline of our framework doesn't support it and the query system doesn't allow specification of unioned queries (how would you specify multiple projections in native llblgen pro query api?)

Those are the reasons union isn't supported in linq. I'm sorry you need it, so you've to work around it. (work around it by doing two queries, that's the only way of doing this.)

If I do a linq query that ends up with

select new {something = somefield}

you can generate valid sql and execute that just fine...

So, if I have TWO of these queries where the select was exactly the same, you can just put UNION/UNION ALL between them and it will work.

I have worked around this by creating a view....but would just like to point out that I know you can figure out a way to support this - even if limited and really think you need to support this to have a 'full' linq provider.

That is just my opinion to help your product. We are still happily using your product.

WayneBrantley wrote:

If I do a linq query that ends up with

select new {something = somefield}

you can generate valid sql and execute that just fine...

So, if I have TWO of these queries where the select was exactly the same, you can just put UNION/UNION ALL between them and it will work.

I have worked around this by creating a view....but would just like to point out that I know you can figure out a way to support this - even if limited and really think you need to support this to have a 'full' linq provider.

That is just my opinion to help your product. We are still happily using your product.

It's not that I'm not capable of eventually coming up with a way to do this, it's just that it's very unpractical to add it for the querying api because there's no construct currently which allows this, and secondly, it's not easy to add this inside the query system, as there's no notion of holding off a query, generate another one, append it etc.. It's easier said than done, if it was easy it would already be in the query api.

Of course a special code path might be solving it, but only for one case. Consider a union in a set which is part of a subquery in a where clause

I know it will make things easier, and if I could do things over again I would opt for a 'Query' object instead of the elements we use today, but alas, that's not going to chance now, I'm afraid. I can hack it in but only for the outside projection, which still doesn't really make sense because there are other scenario's for union as well.

'Full' is a reference to all those linq providers out there which say they support linq but actually only do simple selects and some where clauses. There are more linq extension methods which aren't implemented, for example because they don't make sense in a DB context or are impossible to do in a db context. If I recall correctly, the only two things we don't support are union and skipping (a skip call without a take so that they can be used to define a page). For comparison, the EF can't do contains, which IMHO is much more severe than the lack of union ever will be.

Understood.....just know if you get the chance, union is pretty common. We can do views of course...but if I wanted to do views, I would not really need 90% of the link features.!!

As always, thanks for a great product...

WayneBrantley wrote:

Understood.....just know if you get the chance, union is pretty common. We can do views of course...but if I wanted to do views, I would not really need 90% of the link features.!!

I know what you mean . We'll likely never add it to the native query api, as it's simply too awkward to fit in (as it requires a 'Query' element, which immediately makes the whole query system obsolete, as it's a change of concept). Adding it for linq is a bit of a problem as well: for connecting two resultsets in the final projection, that is doable, but Linq also allows .Union elsewhere in the code, e.g. in filters, subqueries and the like. This immediately gives the awkward situation where these queries will fail at runtime but others wont (the case where you use union in the outer projection). This is perhaps explainable through documentation, the problem kicks in when a person all of a sudden appends a .Where() to the query or other extension method: then the outer projection becomes a subquery and the union fails... That's not obvious for the developer (and also shouldn't it be the developer's problem), so we're actually in a position where we either have to make the choice of adding a lame shortcut which will fail in many situations (not really something we'd want) or adding it to the query system with a Query class which will actually mean a totally new query system (not really something we want either).

So perhaps we'll bite the bullet and implement the Query class and hope it won't be that awkward for people. But I can't promise anything at this point, I'm sorry.