<p>How does this compare with other high-level Haskell db libraries?</p>
<p>Tom</p>
<div class="gmail_quote">On Sep 13, 2012 2:25 PM, &quot;Boris Lykah&quot; &lt;<a href="mailto:lykahb@gmail.com">lykahb@gmail.com</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am happy to announce a new version of Groundhog, a library for fast<br>
high-level database access:<br>
    <a href="http://hackage.haskell.org/package/groundhog" target="_blank">http://hackage.haskell.org/package/groundhog</a><br>
    <a href="http://hackage.haskell.org/package/groundhog-th" target="_blank">http://hackage.haskell.org/package/groundhog-th</a><br>
    <a href="http://hackage.haskell.org/package/groundhog-postgresql" target="_blank">http://hackage.haskell.org/package/groundhog-postgresql</a><br>
    <a href="http://hackage.haskell.org/package/groundhog-sqlite" target="_blank">http://hackage.haskell.org/package/groundhog-sqlite</a><br>
<br>
Groundhog has been completely overhauled since the last release.<br>
Notably, it got support for PostgreSQL and natural foreign keys. I<br>
believe that it is a big step forward as this brings more flexibility<br>
to the design of the relational schemas while keeping the applications<br>
independent of the storage layer. Some of the solutions, particularly<br>
schema migration were based on Persistent code.<br>
<br>
Please see examples at <a href="http://github.com/lykahb/groundhog/tree/master/examples" target="_blank">http://github.com/lykahb/groundhog/tree/master/examples</a>.<br>
<br>
Features:<br>
* Support for Sqlite and PostgreSQL.<br>
* Natural and composite foreign keys. Earlier it was possible to<br>
reference an entity only by the mandatory integer primary key. Now an<br>
entity can have several keys including autoincrement primary key<br>
(optional) and unique keys which have one or more columns.<br>
* Full support of embedded datatypes. You can access a field that<br>
contains an embedded datatype as a whole, or access some of the inner<br>
subfields individually. This powerful mechanism has allowed<br>
implementation of the composite keys, and can be used in future to<br>
work with PostgreSQL composite types or MongoDB embedded documents.<br>
Instead of serializing value to string, the Groundhog backends flatten<br>
tree of embedded datatypes to db columns.<br>
* Projections. You can choose what columns to query from a table in a<br>
type-safe manner.<br>
* Initialization and migration of database schema.<br>
* Sum types and polymorphic types.<br>
* Expression DSL for use in queries.<br>
* Basic list support.<br>
* YAML-based settings mechanism. It separates datatype definition and<br>
description which facilitates modularity. The settings are inferred<br>
from the analysis of the difinition, and overridden with values set by<br>
user.<br>
<br>
The Criterion benchmarks are available at<br>
<a href="http://lykahb.github.com/groundhog/SqliteBench.html" target="_blank">http://lykahb.github.com/groundhog/SqliteBench.html</a> and<br>
<a href="http://lykahb.github.com/groundhog/PostgreSQLBench.html" target="_blank">http://lykahb.github.com/groundhog/PostgreSQLBench.html</a>.<br>
<br>
Future plans:<br>
* Support for joins<br>
* Database indexes<br>
* Investigate options for implementing MongoDB and MySQL backends<br>
<br>
Your feedback, suggestions for improvement and criticism are welcome.<br>
<br>
--<br>
Regards,<br>
Boris<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div>