[Haskell-cafe] GSOC Proposal 2012 : HDBC
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. (models.py in
Django and *tablename*.hrl in Amnesia)
I would like to make developement in HDBC so that all Database interactions
are made through Haskell Native data type.
For eg -
In using Erlang Database interface through Amnesia on would write (Quoting
example from Amnesia Documentation)
populate() ->
{ok, Pid} = amnesia:open(sales),
%% adding customer
{ok, Cust1} = amnesia:add_new (Pid, #customer {customer_code =
102341, name = "John", address = "X", email = "john@xxx"}),
%% adding product
{ok, P1} = amnesia:add_new (Pid, #product { product_code = "001",
description = "CPU Intel", price = 231.10 }),
%% now let's add an order for customer "Cust2"
{ok, Order} = amnesia:add_new (Pid, #orders { order_number = 30,
order_date = {2008, 7, 17}, customer = Cust1 }),
Here each Erlang record (#customer, #product and #orders) are responsible
for different Database Tables. So writing the first statement inserts into
database and return an object Cust1 that can be used late down the line to
create an order table object.
In Django through Python one would have written:
customer = Customer.objects.create(customer_code=102341, name = "John",
address = "X", email = "john@xxx" )
order = Orders.objects.create(order_number = 30, order_date = {2008, 7,
17}, customer = customer)
Writing everything through Language type increases more readability inside
the code. Additionally this helps in abstracting the logic in code from the
underlying SQL being executed. In addition to the support for select,
insert, update queries the my work would extend support for Joins,
aggregations etc all in Haskell Native Types.
I would also like to work to handle the database queries from wire formats/
binaries instead of strings as is the case currently. I would like to close
down these two features as a GSOC project during the summer of 2012 and I
would your feedback on the same.
--
Regards
Pranjal Pandit
Don't communicate by sharing memory; share memory by communicating.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GSOC Proposal 2012 : HDBC
Hi Pranjal, We are glad you are interested in the GSoC. Please take a look at persistent: http://www.yesodweb.com/book/persistent It performs queries and serialization based on Haskell records. It also uses native drivers rather than HDBC. I created a proposal outline [1] and there is a student submission for it [2] [1] http://hackage.haskell.org/trac/summer-of-code/ticket/1605 [2] http://hackage.haskell.org/trac/summer-of-code/ticket/1605 Let me know if you are interested in that or need help coming up with a proposal Thanks, Greg Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSOC Proposal 2012 : HDBC
pranjal pandit 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSOC Proposal 2012 : HDBC
On Wed, Apr 4, 2012 at 7:59 PM, MightyByte wrote: > pranjal pandit 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. This isn't exactly true. persistent-sqlite has its own low-level layer based on direct-sqlite[1], but the other three backends each use an existing low-level library (postgresql-simple, mysql-simple, and mongoDB). Michael [1] http://hackage.haskell.org/package/direct-sqlite ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
