--- Log opened Sun May 26 00:00:21 2013
01:01 < conseo> mcallan: code fixed, db transfer written, yet it seems you have added a new column: org.postgresql.util.PSQLException: ERROR: column "carryvolume" does not exist
01:01 < conseo> will have a look into it tomorrow. gn8
--- Log opened Sun May 26 07:16:35 2013
09:56 < conseo> forgot to run vocount umount; vocount first
10:22 < mcallan> you just have to unmount it manually then.  drop the db schema and remove the corresponding files
10:23 < mcallan> btw, you're right about VoterInputTable.  it's the best name
10:24 < mcallan> (back after breakfast)
12:05 < conseo> ok
15:54 < conseo> the dart sector is triggering new vote inserts when it is being set. i don't understand how this works, somehow it doesn't seem to carry the candidate :-/
16:02 < conseo> i'll try to resetTime() in its setter, hope this works
16:12 < mcallan> the mount may read a vote, change its sector, and re-write the vote.  see ReadyDirectory.NodeThrower
16:19 < mcallan> what i just said ^^ indicates a possible race condition...
16:20 < mcallan> (not that this is likely connected with the bug you see)
16:24 < mcallan> looks like it could possibly clobber a user's vote shift.  i'll fix it (maybe removing dart sector from voter input table) after i pull your changes.  it's not likely to affect you
17:46 < conseo> no, probably not. the input table does not support delete or update anymore, so worst was order mixups, but it is all fine so far
17:46 < conseo> (order related)
19:40 < conseo> mcallan: why is ReadyDirectory "remounting" the votes from xml (in the snap directory), instead of the db input table alone?
19:40 < conseo> can i remove it safely to force it recalculate the mount from the in_vote table?
19:44 < mcallan> remount must produce exactly the same count.  mount does not mean count, it just means to make a count useable
19:44 < conseo> http://zelea.com/project/votorola/s/manual.xht#line-vocount
19:44 < conseo> under mount it says "Count the votes"
19:45 < mcallan> true, because that's what it takes to make the count useable :-)  ...
19:46 < mcallan> but see snap
19:48 < mcallan> you are thinking we should use input table now as archive...
19:48 < mcallan> but input table is not available to public, where archive is.  the whole purpose is to have verifiable counts
19:51 < mcallan> http://zelea.com/project/votorola/a/count/verification.xht
20:00 < conseo> you could just make a dump every 24h hours for the last 24h (and optionally put it in json) from the VoterInputTable now
20:03 < conseo> (i can do so, if you like, btw., providing a cmd-util for cron)
20:04 < mcallan> you were timestamping so as not to lose info.  i would finish that job first...
20:06 < mcallan> then if there's another problem to solve, let's look at it.  u are already coding a count engine of your own, which would have its own verification interface, etc
20:08 < conseo> its one line in clojure (+ cmd line wrapper). its just that this intentionally falls out of the design. that is the whole point of the timestamping imo, that we have plain user data to mirror and share
20:08 < conseo> it should not be the result of a computation unless necessary imo
20:09 < mcallan> what problem are you talking about?
20:10 < conseo> i don't understand how my input table lands in the snap directories, somehow it happens in the count process, but it is not the same data. the timestamp is lost and everyting is beginning of unix time
20:11 < conseo> but reasoning about it, i don't see why we need the xml now.
20:12 < mcallan> SVR http://zelea.com/project/votorola/a/count/verification.xht
20:14 < mcallan> it's not possible to verify count without the snapshot
20:23 < conseo> ok
20:27 < mcallan> later, we might replace snap with api onto VoterInputTable.  probably that's best.  but we don't necessarily need it for early practice trials
20:31 < mcallan> am going for a run, c.  probably you found it already, but you need to patch up VOCount.  it still thinks timestamp is in xml column
20:32 < mcallan> (back in a while)
22:18 < conseo> mcallan: timestamp issue fixed, voting now works both from command line with "voter" and from wicket
22:20 < conseo> wicket's cache seems to be confused though, whenever i umount and mount it still shows the old values cached for me. maybe i am doing it too quickly
22:38 < mcallan> wicket may get confused when tomcat restarts.  maybe that's it.  see item 3 here: http://zelea.com/project/votorola/s/manual.xht#Web-Init
22:39 < mcallan> it should not get confused by vocount running.  or at least nothing a reload won't fix
22:40 < mcallan> (wicket does not actuall cache, afaik)
22:51 < mcallan> anyway, thanks for adding this c.  it's a step in the right direction
22:51 < mcallan> i'm off for the night.  cu soon
23:55 < conseo> my patch-set is ready to pull; here is the update script for the db https://github.com/ghubber/voto-table-migra
23:55 < conseo> gn8
--- Log closed Mon May 27 00:00:46 2013