In DBLX 1.6 we added the ability to use sub-selects in SQL queries. We had planned to implement this early on, but during our initial implementation we found that the sub-select and table joins are actually not similar as we had initially thought. We tried to implement one mechanisim that could handle both, but it was clearly only giving us one right answer or the other.
So, we released with the ability to have joins and deferred sub-selects until just recently.
We decided to redesign the feature to look more like a hierarchy of steps.
In DBLX you can pass multiple queries to the DB engine and then execute all of them when you want to. This means that DBLX has to execute Steps that comprise a transaction. When you have a subselect, you have one step in your transaction that is a SELECT query with child SELECT queries.
The obvious change for us was to allow our Step class to contain child steps. When the SQL parser recognises a subselect, it parses out the individual select statements and connects each Step as a child of the main Step. Then when the execution plan executes a step, it just runs the steps from the end points back up to the top-level parent and connects the record set results from each.
It allowed us to change one method and modify the Step class and that was all we did to support subselects.
We are still testing the new feature, but since it is working well and actually 'looks' correct in source code it appears ready to handle whatever recursive SQL SELECT-hell you want to put it through.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In DBLX 1.6 we added the ability to use sub-selects in SQL queries. We had planned to implement this early on, but during our initial implementation we found that the sub-select and table joins are actually not similar as we had initially thought. We tried to implement one mechanisim that could handle both, but it was clearly only giving us one right answer or the other.
So, we released with the ability to have joins and deferred sub-selects until just recently.
We decided to redesign the feature to look more like a hierarchy of steps.
In DBLX you can pass multiple queries to the DB engine and then execute all of them when you want to. This means that DBLX has to execute Steps that comprise a transaction. When you have a subselect, you have one step in your transaction that is a SELECT query with child SELECT queries.
The obvious change for us was to allow our Step class to contain child steps. When the SQL parser recognises a subselect, it parses out the individual select statements and connects each Step as a child of the main Step. Then when the execution plan executes a step, it just runs the steps from the end points back up to the top-level parent and connects the record set results from each.
It allowed us to change one method and modify the Step class and that was all we did to support subselects.
We are still testing the new feature, but since it is working well and actually 'looks' correct in source code it appears ready to handle whatever recursive SQL SELECT-hell you want to put it through.