Thanks, Greg. On Wed, 2010-02-17, Greg Stein wrote: > WORKING_NODE rows exist for *all* affected nodes.
Meaning all (grand)children of any affected directory as well, I take it. OK, Bert confirmed on IRC. Fixed. > ACTUAL_NODE rows may exist w/o a corresponding WORKING_NODE row (in > which case, there better be a BASE_NODE row). OK, fixed. I added overall doc strings to each table in r911348, incorporating the above fixes and making sure I say "table row" rather than "table entry". > In the comments, we should be better about stating null rather than > NULL (as the latter indicates a NULL pointer, not the SQL null value). I suppose we could, but I think of "NULL" as indicating a computer-language keyword and "null" as English prose, not one for C code and the other for SQL. In the context of pure SQL documentation, there is no ambiguity because there are no C pointers, but where C and SQL co-exist (in C code) I think we'll have to employ more words rather than letter case differences to distinguish them. > moved_here is 1 or something else. There is no need to have a tri-state. I'll leave it alone. > Your comment with respect to moved_to is incomplete. There are more > possible states than just 'base-deleted' and 'normal'. You could also > have (at least) 'not-present' on a child. Consider the sequence: MOVE > A to B. COPY C to A. DELETE A/D. The A/D child will be not-present. OK, I'll just delete the attempt to explain that within the "moved_to" column, because that is not the best place. Committed those remaining comment tweaks in r911393. Thanks for the review. - Julian
