[Haskell-cafe] Subject: A universal data store interface

[Michael Snoyman]

You make it sound like your options are "use the crippled abstraction
layer" or "use the full-powered database layer." You're leaving out
two very important points:

1. There's a reason the abstraction layer exists: it can be clumsy to
go directly to the full-powered database for simple stuff.
2. You can bypass the abstraction layer whenever you want.

I like to describe Persistent's goal as doing 95% of what you need,
and getting out of your way for the other 5%. You can write raw SQL
queries with Persistent. I use this for implementing full-text search.
I haven't needed to write deep analytical tools recently, but if I
did, I would use raw SQL for that too.

Persistent's advantage over going directly to the database is concise,
type-safe code. Are you really telling me that `runSql "SELECT * FROM
foo where id=?" [someId]` plus a bunch of marshal code is better then
`get someId`?

Michael

On Mon, Feb 13, 2012 at 9:53 PM, Paul R <paul.r.ml at gmail.com> wrote:
> I have quiet a lot of experience in the business of web services
> strongly backed by data stores, in a company that allowed me to apply
> a technologies such as RubyOnRails, DataMapper, PostgreSQL, Redis, Riak,
> HappStack and Snap. Greg, with no offense intended, I will share with
> the café a conclusion that we took year to draw, but that made out job
> much better since : Abstraction over high level data stores is one of
> the worst idea in software engineering.
>
> The most proeminent example is probably PostgreSQL, which is an
> incredibly strong product with high SQL power. But as soon as you access
> it through the ActiveRecord or Persistent API, it gets turned into
> a very limited store, with the SQL power of SQLITE or MongoDB.
>
> So Sergiu, my POV is that universal data stores is at best a glue
> targeting small projects, so that they can be hacked quickly. They offer
> a set of features that, by design, is the greatest common divisor of the
> backends, which unfortunately isn't that great. This is certainly nice
> for a do-a-blog-in-5-minutes with "MyFramework init" video tutorial, but
> probably not for industrial projects in the long run.
>
> As a side note, the acid-state package that Greg kindly mentioned, takes
> a very different approach to data storage, resulting in
> a haskell-centric solution with an original features set.
>
> Regarding your other option, the value behind the LLVM backend seems
> huge for the whole Haskell community. It has the power to lighten GHC,
> improve runtime performance, bring binaries to more platforms and much
> more. In my opinion, that's quiet exciting :)
>
>
> Greg> Hi Sergiu,
> Greg> Thanks you for your interest in that proposal. I rushed it off a year
> Greg> ago. Since then we have made a lot of improvements to Persistent and
> Greg> the library forms a basic building block for most Yesod users and
> Greg> other Haskellers. Persistent offers a level of type-safety and
> Greg> convenience not available elsewhere (except perhaps for libraries like
> Greg> acid-state that are limited to in-memory storage). That being said,
> Greg> there are still a lot of improvements that could be made. With the
> Greg> effort of a GSoC volunteer we could probably get it to the point of
> Greg> being the go-to data storage library for Haskellers, at least those
> Greg> planning on using the subset of backends (likely SQL) with great
> Greg> support. This proposal is vague and we would need to work with you to
> Greg> narrow things down a bit.
>
> Greg> I am biased, but I believe the Yesod project is one of the most
> Greg> compelling in the Haskell ecosystem. There are a lot of different ways
> Greg> a GSoC project could help make things even better besides improving
> Greg> the associated Persistent library, and we would really like to mentor
> Greg> at least one GSoC student. I would open more tickets for this in the
> Greg> system, but I am not sure how helpful it will be. It seems that we
> Greg> need to reach out to more students like yourself, but I am not sure
> Greg> how to do that unless I see messages like these first.
>
> Greg> Greg Weber
>
> --
>  Paul
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe