Hackage 2 and acid-state vs traditional databases

[Leon Smith]

On Thu, Sep 6, 2012 at 2:49 PM, Ian Lynagh <ian at well-typed.com> wrote:

>
> * Only a single process can use the database at once. For example, if
>   the admins want a tool that will make it easier for them to approve
>   user requests, then that tool needs to be integrated into the Hackage
>   server (or talk to it over HTTP), rather than being standalone.
>


This much is wrong;  acid-state does have functionality for
accessing/modifying the database from other processes,   namely
System.Data.Remote,  but I haven't investigated deeply.

That said,  I think there would be some potential advantages of moving to
SQL.   My personal preference would for PostgreSQL,  particularly because
of the wealth of datatypes it provides,   or can be added to it via already
existing third-party plugins.    Compared to MySQL,  it's definitely less
fluff,  more stuff.

For example,  the schema I sketched out for the account request processing
uses hstore,  which is an extension (included with the standard postgres
distribution, even)  that provides a field of type (Map String String),  to
store both public profile information as well as HTTP headers the client
sent with the request,  as well as indexes on that type.    Or,  we might
store module names using the ltree extension,   which is a perfect match
for the problem:  PostgreSQL would then understand the components of the
module name,  be able to index those,  and provide a variety of additional
operators to query them.

http://www.postgresql.org/docs/9.1/static/hstore.html
http://www.postgresql.org/docs/9.1/static/ltree.html

Also, the rules and trigger systems provided by PostgreSQL are considerably
more capable than anything in MySQL,  which allow you to do things such as
create updateable views (with some work).     Also, I find PL/pgSQL and
asynchronous notifications particularly useful,  and while I don't know
MySQL well enough to definitively say that MySQL has no answer to these
features,   there isn't anything obvious that is as simple and powerful as
asynchronous notifications nor as fully featured as PL/pgSQL.    (And,
 there are a ton of other PL/*** languages out there,  somebody even has a
very rudimentary start on PL/Haskell.)

One of the most common use cases for asynchronous notifications is to be
able to efficiently and robustly respond to changes made to a database.
 (Robust in the sense that the client making the change doesn't know that
other processes need to be informed of said change,  as this will instead
be handled by a trigger that NOTIFYs the interested clients.)

Best,
Leon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/cabal-devel/attachments/20120906/3386309e/attachment.htm>