machines value constraints: needed cleanup and decisions

[gsrohde]

Decide on what value constraints should be used.

We should probably wait to do this until pull request #217 is dealt with (or do them in conjunction).

[dlebauer]

• hostname = ip address. (I've fixed the offending dlebauer-desktop
• created_at, updated_at > 2010-01-01

[gsrohde]

After the migration AddSyncId is applied (see pull request #217), this table will have the following columns and constraints:

    Column    |              Type              |                       Modifiers                       
--------------+--------------------------------+-------------------------------------------------------
 id           | bigint                         | not null default nextval('machines_id_seq'::regclass)
 hostname     | character varying(255)         | not null
 created_at   | timestamp(6) without time zone | 
 updated_at   | timestamp(6) without time zone | 
 sync_host_id | bigint                         | 
 sync_url     | character varying(255)         | 
 sync_contact | character varying(255)         | 
 sync_start   | bigint                         | 
 sync_end     | bigint                         | 
Indexes:
    "machines_pkey" PRIMARY KEY, btree (id)
    "unique_hostnames" UNIQUE CONSTRAINT, btree (hostname)
    "unique_sync_host_id" UNIQUE CONSTRAINT, btree (sync_host_id)
    "index_machines_on_hostname" btree (hostname)

The TimeConstraints migration (see pull request #264) will impose constraints on created_at and updated_at.

A possible additional constraint is

ALTER TABLE machines ADD CONSTRAINT unique_sync_urls UNIQUE (sync_url);

(@robkooper Is this a reasonable constraint?)

An obvious additional constraint is to ensure ranges implied by (sync_start, sync_end) are non-overlapping, but this is complicated to implement. For now, we will probably implement this only in the Rails interface for adding and updating machines. At some later time, we may wish to replace these to columns by a single range-type column, which would make ensuring non-overlapping ranges much simpler. Unfortunately, Rails 3 does not natively support PostgreSQL range types.