--- Log opened Fri May 24 00:00:46 2013
09:23 < conseo> hmm, a vote is more than a message (which at least would have a timestamp and a sender + payload), it also has a clear direction as its main quality. if we consider the candidatename as a url in the sense of unique and global (which we should to keep tool compatibility imo.), then i don't see how it can overfit what a vote is. if we keep it opaque in a string, we cannot query the voters of a candidate, especially not
09:23 < conseo>  for any point in time for instance, without pulling all data in java memory to do the joins there manually
09:26 < conseo> on the other hand if we pull it in and have votes which point to some form of aggregate which cannot be represented as an url, then we can still set the candidate null in the table and put the information again in the xml. note that ambiguous candidates don't make a lot of sense, most likely would be a ranked list
09:30 < conseo> but even then a schema change in a single table is no big drama, a problem is when we have to update several at once.
09:32 < conseo> i am just complaining, because a search index on candidate over all historical data would give more powerful exploratory queries and a better playground to explore the data, while the xml is completely opaque
09:34 < conseo> also for a ranked aggregate, we could still put the first candidate of the list in and have canonical backwards compatibel information and other tools aggregate's need translation anyway
09:34 < conseo> which problem are you hedging against?
11:56 < mcallan> no problem, really.  since no problem is caused by the lack of a candidate column, i say there should be no candidate column to "solve" it
11:57 < mcallan> if and when we need a candidate column, then we can add it.  but not before.  otherwise we end up with a confusion of purposeless solutions, which is the sign of a bad design
12:00 < mcallan> anyway, that's how i designed it originally.  i just don't see a problem with it, and therefore no need to change it
12:02 < mcallan> conseo: but if you see a problem, please explain
12:03 < mcallan> i am not against it if there's a need
18:31 < mcallan> i'm off for the day, c.  let's talk soon if you need this column.  i just want to understand the reason.  as a rule, i don't expose data unless it's needed by clients
19:23 < conseo> this means we can only query the vote data from bottom root-wards (voter to candidate), not from top to bottom, without reading and recalculating the data in memory first
19:25 < conseo> we cannot ask a question in SQL like: on dec. 3rd who voted for X, although this is perfectly fine in SQL. since this is our input data, which we mirror as well to other tools, i would like to have this information accessible. everything else can go into xml, but this information is actually core of each datum
19:26 < mcallan> i'm still here, c.  can u mumble?
19:27 < conseo> i don't need it in the sense that i can't extract it, it will only help once the data gets bigger and we want to explore it. i mean i can do this queries during live coding to experiment with sql and data
19:27 < conseo> mcallan: yes
19:28 < mcallan> ok
--- Log closed Sat May 25 00:00:04 2013