On Sat, Jan 21, 2012 at 3:18 AM, Guilherme Salgado
<guilherme.salg...@linaro.org> wrote:
> Oh, I'm also attaching the SQL for the new tables we think would be
> necessary for this.
We can worry about the indexes and such later when this becomes more
solid. I'm curious why you have chosen date instead of timestamp for
some of the columns - I see no reason to throw away the extra
accuracy, and a 'date' doesn't really make sense across timezones
where your Monday is my Tuesday.
Our replication setup requires every table to have an explicitly
declared primary key. I think you want specificationworkitemstats to
have its 'specification' column declared as a primary key (in addition
to referencing the specification table), which will also ensure the
column is unique. If this column is not unique, we will need a SERIAL
PRIMARY KEY added to keep replication happy (and ensure that *we* are
able to uniquely address rows too :) )
CREATE TABLE specificationworkitemstats (
specification integer PRIMARY KEY REFERENCES specification,
date date NOT NULL,
status integer NOT NULL,
assignee integer REFERENCES person,
milestone integer REFERENCES milestone,
count integer NOT NULL);
--
Stuart Bishop <stuart.bis...@canonical.com>
_______________________________________________
Mailing list: https://launchpad.net/~launchpad-dev
Post to : launchpad-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~launchpad-dev
More help : https://help.launchpad.net/ListHelp
