On Fri, Mar 11, 2011 at 02:13:05PM -0500, Greg Stein wrote:
> On IRC, there was a discussion about the wc_db API. In particular
> whether to have lots of query functions, or to have the caller sort it
> out. As Bert noted, my original intent was to provide the caller with
> enough information and let it sort everything out. That keeps the API
> cleaner, and it also moves the filtering out of wc_db. Generally, the
> particular pattern/rules of filtering changes with almost every
> caller. It is pretty hard for wc_db to provide generic mechanisms for
> filtering.
This design sounds like it goes against what I've been doing for the revision
status code. For each bit of information the revision status code wants,
I wrote a separate query and then exposed it in the wc_db API.
The result is not perfect as-is (it is using multiple independent queries
which isn't transactional). But in general, I would regard wc_db more as a
glue layer to the SQL. It's an internal, and private (read: flexible and
easily amendable), API that we use to pull structured information out of the
sqlite DB using SQL queries. Each API call provides answers to a particular
question, and under the hood the question is formulated in SQL so that
sqlite can find the answer for us. The filtering isn't general (it's
encoded in the SQL query), but highly effective. And it performs well.
The APIs that simply provide information but don't do any filtering
(e.g. read_info()) will never perform as well. The way they are written
they're even restricted to acting on a single node in the working copy.
The per-path approach is something we've inherited from wc-1, and was
necessary for the transition phase to keep a working implementation
we can test. But it is unnecessarily restrictive in the new wc-ng world.
If we keep using APIs like that, we might as well get rid of sqlite and
use a custom flat-file format again that acts as a key-value store for
data keyed by paths -- using sqlite for that is overkill.
Brane noted that filtering in SQL could be generalised by parametrising
the queries a bit more. I'm OK with that, as long as it doesn't result
in generic and over-long queries nobody will be able to understand.
The beauty of specific queries is that it's perfectly clear what they're
asking for, and what the result should be. I don't mind having many of them.
Received on 2011-03-12 14:15:29 CET