Re: [PATCH 1/2] Support publishing build events

[Christopher Baines <mail@cbaines.net>]

[-- Attachment #1: Type: text/plain, Size: 1685 bytes --]


Clément Lassieur <clement@lassieur.org> writes:

> Christopher Baines <mail@cbaines.net> writes:
>
>> diff --git a/src/schema.sql b/src/schema.sql
>> index a9e4a6a..b84b231 100644
>> --- a/src/schema.sql
>> +++ b/src/schema.sql
>> @@ -64,6 +64,18 @@ CREATE TABLE Builds (
>>    FOREIGN KEY (evaluation) REFERENCES Evaluations (id)
>>  );
>>
>> +CREATE TABLE Events (
>> +  id            INTEGER PRIMARY KEY,
>       ^
> Also, I forgot.  This row could be removed if the EventsOutbox table is
> removed.
>
>> +  type          TEXT NOT NULL,
>> +  timestamp     INTEGER NOT NULL,
>> +  event_json    TEXT NOT NULL
>> +);
>> +
>> +CREATE TABLE EventsOutbox (
>> +  event_id      INTEGER NOT NULL,
>> +  FOREIGN KEY (event_id) REFERENCES Events (id)
>> +);
>> +
>
> And now that I think about it, even if we don't remove the EventsOutbox
> table, wouldn't it be simpler to just add a 'sent' column (a Boolean) to
> the Events table?

Simpler definitely in terms of the schema. However, I was thinking more
of the separation of concerns. One concern is storing events, and the
other is delivering them, and each table handles just one of those
things.

Also, I think at least in PostgreSQL, updating a row in a table
effectively inserts a new version of the row with the update, then at
some point the space for the old version of the row may be reused. Given
the events table may become quite large, it will probably be easier to
handle as something that's just added to, not added to and then
modified. But, I realise this is me guessing about performance and
maintenance without knowing much about SQLite, or doing any testing…

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 962 bytes --]