This will avoid many queries trying to figure out what the latest build status
is, which will hopefuly simplify queries as well as improving performance.
Move the logic from different places in the view code, and also start
supporting linking to guix.cbaines.net builds. I'm unsure quite how to
generalise this, but just starting doing it is probably the way forward.
I've see this error [1] which may relate to the derivation-output-details-id
not being a number, so this check should confirm if there is a issue.
1: Throw to key `psql-query-error' with args `(fatal-error "PGRES_FATAL_ERROR" "ERROR: invalid input syntax for integer: \"\"\n")'.
Previously, if an exception occurred during the processing of any but the last
letpar& expression, the replies for the other expressions would never be
fetched, resulting in that thread in the pool just waiting for a receiver for
the message.
To avoid this, make sure to read all the replies before raising any
exceptions.
Previously the package_derivations table wasn't considered, which would mean
derivations would still be referenced. This commit fixes that, along with also
deleting unreferenced entries in some linter related tables.
Some revisions have got disassociated from branches, probably because they
were associated with multiple branches in the first place. This should allow
deleting them.
Channels don't represent some channel on which messages travel, at least not a
very long one because it can't accommodate any messages. They simply represent
a direct exchange of the message between a sender and receiver. Because of
this, put-message blocks the fiber, and if all the threads on the other end
are waiting for replies to be received, then you have a deadlock.
To avoid this situation, spawn new fibers to send the messages. I think this
works at least, although I'm unsure how sensible it is.
Previously, a connection was passed through the code handling the
request. When queries were performed, this could block the thread though,
potentially leaving the server unable to serve other requests.
Instead, this now runs queries in a pool of threads. This should remove the
possibility of blocking the threads used by the web server, and in doing so,
some of the queries have been parallelised.
I''m still not sure about the naming and syntax, but I think the functionality
is a sort of step forward.
