[Haskell-cafe] GSOC Proposal 2012 : HDBC

[MightyByte]

pranjal pandit <pranjal5215 <at> gmail.com> writes:

> 
> 
> Hi,I would like to work on improving the HDBC as a GSOC project 2012. I have
> a previous working experience with Django and its ORM and I had a look at
> Amnesia (http://amnesia.sourceforge.net/user_manual/manual.html) which is a
> SQL database interface for Erlang.
> 
> Few of the features of both include:
> 1 ) Database operation are supported through Language Native types.
> 2 ) Direct table creation from native language constructs.

Hi Pranjal,

Here are some things to consider when writing your proposal.

Haskell RDBMS libraries exist on two different broad levels of abstraction.  
There are low-level libraries that provide the ability to write raw SQL queries 
and retrieve the results, and there are high-level libraries that do more 
sophisticated things.  These high-level libraries are more of what you're 
probably thinking about when you think ORM.  HDBC and others like mysql-simple, 
postgresql-simple, etc are in the low-level category.  The high-level category 
has libraries like haskelldb, persistent, and groundhog.

In some cases the high-level libraries are written using a low-level library as 
the back-end.  Haskelldb is a good example of this because it uses HDBC for its 
low-level access.  HDBC provides a uniform interface for working with MySQL, 
PostgreSQL, and SQLite so by using HDBC, haskelldb works with all these 
databases for free.  However, some high-level libraries like persistent don't 
use a separate low-level library and instead opt to maintain their own code for 
interfacing directly with the database.

There are a number of different approaches one could take in the implementation 
of a "Haskell ORM" like you have described.  It is a big enough problem that I 
think you need to focus on a smaller, more specific goal for a GSoC proposal.  
If you are interested in the high-level ORM side of the problem, check out the 
links Greg Weber mentioned for the persistent project.

Improving HDBC is also a great idea for a project.  It currently has some 
significant performance issues because of its use of String.  There's a ticket 
for this at http://hackage.haskell.org/trac/summer-of-code/ticket/1598.  
Improvements to HDBC would also benefit other high-level libraries like 
haskelldb that use HDBC as a back-end, so Google might consider such a project 
to have more impact per developer hour spent.