Greg Stein <gstein_at_gmail.com> writes:
> I'm with Bert. The entry writing is used *only* for upgrades. It may
> as well be tuned for exactly that: track any information you need
> while performing the upgrade.
I realise we can do that, but I don't see why it's better. It means
creating/using our own database in memory. Why is that better than
using the real database we have just written? It means duplicating
part of of _scan_addition.
> Also remember that the wc.db file that is being constructed during the
> upgrade process really should be called something like wc.db.upgrade
> (see SDB_FILE and SDB_FILE_UPGRADE). We just aren't doing that right
> now. And what *that* means is that the wc_db functions will not work
But that's not hard to fix, when I create the second handle that
ignores 1.6 I can tell it to use the upgrade name.
> during the upgrade process. And really: you shouldn't rely on them.
> You're in a transient state, trying to build a proper database.
You and Bert have both mentioned transient state. What problem do you
see? Why should we be creating some invalid, transient state? We
write parents before children, we don't subsequently tweak the parent,
the parent should be correct before we start on the children. If
_scan_addition gives us the wrong answer during the upgrade how is it
going to work when the upgrade is finished?
[I'm aware that we don't add incomplete children when we add a
complete parent, but the children don't care about siblings. And it
should be easy to fix.]
Received on 2010-08-26 21:02:51 CEST