Quote:
Originally Posted by Starson17
@Charles - do you have any thoughts on whether an SQL search could be integrated into the search query system? (I'm not even sure if SQL will always be used within the library.)
|
This is an interesting question.
First, your "I'm not even sure" is valid. However, it would be close to impossible to implement current calibre functionality without a usable query language, so the question really becomes 'Do you have any thoughts on providing support for semi-arbitrary queries?'
The easy areas is selection: field relop value etc. That is so close to what we do today that I am not worried.
More interesting is the implicit use of functions. Your 'count' example is a good example. And it immediately leads us to the notion of functions (count, average, exists, etc). Any reasonable query system must support these kinds of questions, but perhaps with different syntax.
The third level would be the unraveling of joins, permitting selection by individual multiple items. For example, inside calibre, there are selections that look for a book referencing a particular author, where the query checks against the n-ary connection tables. The same query can be expressed against the book view where the authors are joined together, but there is the possibility of both substring errors and performance problems.
Final level: testing for null using left or outer joins. These are hard. A good example would be a query that finds books with no formats (left join with NULL as the result).
Bottom line: if an arbitrary query language can be defined in terms of a set of well-understood functions, fields, and relops, then I can see building it. This is especially true if the current search capabilities are expressible in the 'language'. This is even more true if the calibre functions like 'set_author' are expressible, but this may be silly. Going beyond that to, for example, raw SQL will require Kovid to make a commitment that I suspect he is unwilling to make.