The challenge with appeneding infixes (that have not been used but are still needed)
back into the query, is that they could be inside of tuples/case-classes that have already
been selected, or inside of sibling elements which have been selected.
Take for instance a query that looks like this:
In this situation, p.id which is the sibling of the non-selected infix has been selected
via p._2._1 (whose select-order is List(1,0) to represent 1st element in 2nd tuple.
We need to add it's sibling infix.
In this case, we have selected the entire 2nd element including the infix. We need to know that
P._2._2 does not need to be selected since p._2 was.
In order to do these things, we use the order property from OrderedSelect in order to see
which sub-sub-...-element has been selected. If p._2 (that has order List(1))
has been selected, we know that any infixes inside of it e.g. p._2._1 (ordering List(1,0))
does not need to be.
The challenge with appeneding infixes (that have not been used but are still needed) back into the query, is that they could be inside of tuples/case-classes that have already been selected, or inside of sibling elements which have been selected. Take for instance a query that looks like this:
In this situation,p.idwhich is the sibling of the non-selected infix has been selected viap._2._1(whose select-order is List(1,0) to represent 1st element in 2nd tuple. We need to add it's sibling infix.Or take the following situation:
In this case, we have selected the entire 2nd element including the infix. We need to know thatP._2._2does not need to be selected sincep._2was.In order to do these things, we use the
orderproperty fromOrderedSelectin order to see which sub-sub-...-element has been selected. Ifp._2(that has orderList(1)) has been selected, we know that any infixes inside of it e.g.p._2._1(orderingList(1,0)) does not need to be.