Changes between Version 4 and Version 11 of Ticket #1605


Ignore:
Timestamp:
Mar 26, 2012 10:26:18 PM (2 years ago)
Author:
gregweber
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #1605 – Description

    v4 v11  
    33Data storage is absolutely critical for web development or any program that needs to persist data or whose data processing exceeds memory. Haskell web development has languished in part because one had to choose between lower-level SQL or Happstack's experimental data store that uses only the process memory. All other widely used programming languages have multiple ORMs for proven databases. Haskell needs some better database abstraction libraries. 
    44 
    5 The persistent library is a universal data store interface that already has PostgreSQL, Sqlite, MySQL and a MongoDB backend. Most users of the Yesod web framework are using it, and it is also being used outside of web development. With some more improvements, persistent could become a great data store interface for haskell programmers. 
     5The persistent library is a universal data store interface that already has PostgreSQL, Sqlite, MySQL, MongoDB, and experimental CouchDB backend. Most users of the Yesod web framework are using it, and it is also being used outside of web development. With some more improvements, persistent could become the go-to data store interface for haskell programmers. 
    66 
    7 What improvements should be made you ask? More backends could be written. There is a pull request for a CouchDB backend that would take just a little time to cleanup. However I believe we are better off mostly focusing on the current supported (SQL & MongoDB) and making them better. 
     7We could create interfaces to more databases, but the majority of Haskell programs just need *a* database, and would be happy with a really good interface to any database. There is also a need to interface with existing SQL databases. So I would like to focus on making (SQL & MongoDB) storage layers really good. MongoDB should be easier to create a great interface for. 
    88 
    9 Note that we have moved Persistent in the direction of universal query interface to just a universal data store serialization interface. There are many critics of query interfaces for good reasons: we will never be able to solve all use cases. 
     9We have moved Persistent in the direction of universal query interface to just a universal data store serialization interface. There are many critics of query interfaces for good reasons: we will never be able to solve all use cases. 
    1010 
    11 I believe future work on Persistent should continue this recent direction of allowing for raw queries. One can now write raw SQL queries but get them automatically properly serialized. The next step is to make them extraordinarily type-safe. That is, we know at compile time that the queries are valid. They reference columns correctly and they are valid database queries. There is already an experimental implementation of this for SQL called persistent-hssqlppp that checks the validity of SQL statements at compile time. 
     11I believe future work on Persistent should continue this recent direction of allowing for raw queries. One can now finally write raw SQL queries and get them automatically properly serialized. The next step is to make them extraordinarily type-safe. That is, we know at compile time that the queries are valid. They reference columns correctly and they are valid database queries. There is already an experimental implementation of this for SQL called persistent-hssqlppp that checks the validity of SQL statements at compile time. 
    1212 
    13 Persistent's biggest limitation right now is the lack of a good technique for returning a projection of the data - we always give back a full record. Tackling this in the GSoC would be great. Another task at hand is to write a convenient Template Haskell interface for declaring a schema, which should only be a few days work because we already have all the tools in place through the Quasi-Quoted DSL. 
     13Persistent's biggest limitation right now is the lack of a good technique for returning a projection of the data - we always give back a full record. This issue should be explored in the GSoC, but does not have to be solved. 
    1414 
    15 There are also some possibilities for integrating with existing Haskell backends. One would be a pure-haskell backend, possibly using happstack's storage system - so that a haskell programmer not be required to have any database dependencies to get up and running, but would always have the option of switching to a battle-tested database later on. Another interesting option is integration with HaskellDB or DSH - HaskellDB is weak because it does not automatically serialize to a Haskell record like Persistent does. 
     15Persistent already has a very good Quasi-Quoted DSL for creating a schema, but another task at hand is to write a convenient Template Haskell interface for declaring a schema. This should not be difficult because we already have all the tools in place. 
    1616 
    17 Michael Snoyman and myself are willing to mentor, and there is a large community of users willing to help or give feedback. 
     17There are also some possibilities for integrating with existing Haskell backends. One interesting option is integration with HaskellDB or DSH - HaskellDB does not automatically serialize to a Haskell record like Persistent does. 
     18 
     19Michael Snoyman and Greg Weber are willing to mentor, and there is a large community of users willing to help or give feedback.