I won’t have much time for KDE development for probably the next month or so due to the fact that I have a ton of assignments to do, including extending an SQL engine in Java in a month. Hmm, that leads me into a rant.
Our team is inheriting the work of last semester’s Java engine. The design is more or less well thought out, even though a lot of the actual implementation is quite hairy. For example, when parsing the select statement, they use regex splits to determine all of the information! They were able to do this because all they needed to determine were the field names and table names, with each being restricted to single words without any other SQL clutter (such as being able to use the AS keyword to alias a field). I realized very early on that since we had to implement: aggregate functions as fields (SUM(foo), MIN(foo), etc), table.field references, the AS keywords, complex WHERE conditions, and the GROUP BY/HAVING/GROUPING SETS keywords, we were going to have to implement a parser.
Seeing as how I wanted this assignment done before I die, I volunteered to implement the parser. I considered Antlr briefly before rejecting it, instead settling on a simple recursive-descent parser. Although work on that is coming along as smoothly as can be expected, one of my team members is nearly freaking out over the fact that we’re adding a parser. It took me a whole day to convince him that the parser would pretty much required if we wanted to get this done, and yet he won’t get over the fact that we might actually have to interface our code with the existing code to get the project to work.
For example, earlier today he asked me whether it would be possible to somehow have the parser split up the complex WHERE queries into a series of simple WHERE queries, which the existing engine was able to handle. I’m surprised that I managed to not lose it right there and then. My parser already implements creating parse trees for the WHERE and HAVING keywords, all you have to do after a successful parse is do parser.whereCondition().matches(row) for each row in the candidate result set to see if it matches or not. It’s not like it’s brain surgery. I’m afraid this guy is going to waste more time trying to dream up ways to not have to write code than he will actually writing code, and it’s pissing me off.</p>