mk-table-checksum doesn't --savesince correctly on empty tables

[GoogleCodeExporter]

If you run

mk-table-checksum localhost --argtable=foo.bar --savesince

and an empty table with an auto-increment ID, then you see in MKDEBUG output:

# main:3566 10847 Finished chunk at 1225656435.32227
# main:3407 10847 Saving --since value: undef for <database> <table>

The undef is because earlier, in TableChunker, we saw

# TableChunker:1976 10847 SELECT MIN(`pk`), MAX(`pk`) FROM ...

and then:

# main:3330 10847 Table: $VAR1 = {maxval => undef,create => ....

As a result, the current timestamp gets saved into the --since column. 
This is not desirable; if there is a --since column against which the
--since value will be applied, then undef ought to be stored.

Original issue reported on code.google.com by baron.schwartz on 2 Nov 2008 at 8:26

[GoogleCodeExporter]

I think I fixed this in r2471 and r2472 but we need a test case.

Original comment by baron.schwartz on 2 Nov 2008 at 9:11

[GoogleCodeExporter]

I'm taking this issue and issue 121 because they have broken many tests which is
keeping me from implementing issue 99 for mk-table-checksum. :-) I'll do/fix 
all 3
issues.

Original comment by dan...@percona.com on 7 Nov 2008 at 1:09

• Changed state: Started

[GoogleCodeExporter]

Ok, as of r2477 the tests are back to normal except for one which is failing 
due to
side effects of r2471 and r2472. (The other failures were related to the test 
script
being a relative mess of inter-related tests, tables, etc.--this is another 
issue to
deal with later.)

I've been looking into these issues closely and I think we're getting our types 
of
sinces mixed up in the code. Tell me, Baron, if my understanding of how this all
should work is correct. If it is, then I'll straighten out the code accordingly.

First, a since criteria is either 1) temporal or 2) "numerical" (e.g. a >= 100;
something that gets appended to the WHERE clause).

For temporal sinces, the table is only checksummed if its update time is newer 
than
the since time. If the table has no update time (e.g. InnoDB, issue 121) then 
it is
always checksummed. For these sinces, whether or not the table has a chunkable 
column
or a maxval does not matter because we're looking only at the table's update 
time and
nothing else. Therefore, the current timestamp is always saved if --savesince.

For "numerical" senses, which come out to be WHERE clauses, nothing is really
"checked" (like we check the table's update time for temporal senses). The only 
thing
that matters for these senses is that there is a chunkable or nibble-able 
column. If
there is: great. If not, then effectively all rows get checksummed and we save 
undef
if --savesince. Or, if there's no max value or not values at all (this issue), 
then
we also save undef if --savesince.

Original comment by dan...@percona.com on 7 Nov 2008 at 4:53

[GoogleCodeExporter]

Yes.

Original comment by baron.schwartz on 7 Nov 2008 at 12:41

[GoogleCodeExporter]

This is fixed and tested as of r2478. All tests pass, though one had to be 
modified
for reasons to be explained later after I do some more documenting. So I'll 
leave
this issue open until then.

Original comment by dan...@percona.com on 8 Nov 2008 at 3:55

[GoogleCodeExporter]

Ok, this is fixed as of r2482 and the code is more clear and documented as to 
what
happens and why regarding --since and --savesince.

Original comment by dan...@percona.com on 11 Nov 2008 at 4:36

• Changed state: Fixed