From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Ayo <ayo(at)blicky(dot)net> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Looking for advice on working with revisions |
Date: | 2010-01-05 14:08:11 |
Message-ID: | 20100105140811.GC3660@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Ayo wrote:
> Inserting a new release and its first revision is done as explained with the
> following pseudocode:
>
> $rid = INSERT INTO releases DEFAULT VALUES RETURNING id;
> $rev = INSERT INTO revisions (type, uid) VALUES('r', $uid) RETURNING id;
> INSERT INTO releases_rev VALUES($rev, $rid, $title, $date);
> INSERT INTO releases_lang VALUES ($rev, $lang1), ($rev, $lang2);
> UPDATE releases SET current = $rev;
>
>
> Inserting a new revision of an existing release is quite similar, except that
> there is no INSERT INTO query for the releases table, and $rid is already known.
>
> This system has worked quite well, but has one problem: every client that wants
> to insert a new revision will have to manually copy over all releases_rev
> columns and releases_lang rows of the previous revision, even if all they want
> to change is just one single column. This in itself is not a problem, but
> whenever a new column or table is added to the database, all clients will have
> to be updated again so that they copy over the new information correctly, which
> is very prone to errors.
I'd say that, like every other CS problem, it can be solved by adding
another layer of abstraction; only that instead of adding stored
procedures as you suggest, add a new relation that sits between
releases_rev and releases_lang (say release_msg). Then you don't
translate a revision -- you translate a message, to which many revisions
can be pointing.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2010-01-05 14:13:49 | Re: access computed field of RECORD variable |
Previous Message | Sam Mason | 2010-01-05 14:06:51 | Re: converting tables to XML and back |