You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here's a simplified SQL query to represent the problem I've encountered:
SELECTT1.id, T1.amount*10AS value FROM T1
UNION ALLSELECTT1.id, T1.amount*100AS value FROM T1
Then lets say have this code to fetch the data:
val q1:Queryval q2:Queryval data = q1.unionAll(q2).alias("data").selectAll()
When inspecting the data returned, only the ID field is present, while the derived column is omitted.
The generated SQL that is logged by exposed is basically like this:
SELECT"data".id FROM (
-- union query per above
) AS"data"
Hence, the derived columns, while present in the subqueries, were completely omitted from the top-level select.
I have noticed when I was dumping data from each query individually that the full formula for each derived column was part of its name/structure, hence leading me to believe that columns are not matched based on their type, and ultimately excluded from the union's column set based on a perceived mismatch -- but this is conjecture on my part.
That said, there is a gap here in being able to fetch data, and a question on how one would fetch the data if it were present, but that was already raised as issue #1253.
This was observed with version 0.35.3.
The text was updated successfully, but these errors were encountered:
dinoklein-ls
changed the title
Union of queries with differently derived columns looses the derived columns
Union of queries with differently derived columns loses the derived columns
Nov 1, 2021
@Tapac can you write a few words on how to fetch the data a union-ed column that has two different expression definitions? Will either "expression" object work to fetch it?
Here's a simplified SQL query to represent the problem I've encountered:
Then lets say have this code to fetch the data:
When inspecting the data returned, only the ID field is present, while the derived column is omitted.
The generated SQL that is logged by exposed is basically like this:
Hence, the derived columns, while present in the subqueries, were completely omitted from the top-level select.
I have noticed when I was dumping data from each query individually that the full formula for each derived column was part of its name/structure, hence leading me to believe that columns are not matched based on their type, and ultimately excluded from the union's column set based on a perceived mismatch -- but this is conjecture on my part.
That said, there is a gap here in being able to fetch data, and a question on how one would fetch the data if it were present, but that was already raised as issue #1253.
This was observed with version 0.35.3.
The text was updated successfully, but these errors were encountered: