2011/3/11 Branko Čibej <brane_at_e-reka.si>:
> On 12.03.2011 01:29, Greg Stein wrote:
>...
>> So. Not a premature optimization, but a design choice.
>
> Six of one, half a dozen of the other. ACTUAL is just another op-depth
> with a few extra attributes, so let's compromise and call it an
> implementation choice, rather than a design choice. :)
No. It was a design choice. Simple as that.
Since the time that design was constructed, we have learned more. We
have refined our models, we have found implementation issues, we have
rebuilt the code into new ways, etc etc. I take issue with your
characterization. We designed with what we knew at the time, rather
than "prematurely optimized" the code or "made an implementation
choice".
>...
> Right now I'm seeing C code do:
>
> * recursive tree walks of the wc-db with per-directory queries
> * programmatic "joins" of data from different tables
> * op-depth filtering on NODES
>
> Much as I try, I can find no good reason, even taking account of the
> considerations you listed above, to /not/ do these in SQL. There aren't
> all that many radically different queries you can do in wc-db anyway.
That may be. But remember the wc_db API was originally designed to
ease the migration from the 1.6 WC mechanisms. Tree walks is how it
worked. There was no SQL, so everything happened in memory. And there
certainly was no "op_depth". So yeah... with yet more work, we can
make the additional changes you describe.
>...
Cheers,
-g
Received on 2011-03-12 04:39:56 CET