No subject

  Persistent follows the guiding principles of type safety and concise,
  declarative syntax. Some other nice features are:

   * Database-agnostic. There is first class support for PostgreSQL,
     SQLite and MongoDB, with experimental CouchDB and MySQL support in
     the works.
   * By being non-relational in nature, we simultaneously are able to
     support a wider number of storage layers and are not constrained by
     some of the performance bottlenecks incurred through joins.
   * A major source of frustration in dealing with SQL databases is
     changes to the schema. Persistent can automatically perform database
     migrations.

You raise a good point mentioning that persistent has raw queries
facilities. That certainly makes is suitable for complex queries, but as
soon as you do so, you are not anymore store-agnostic, so this part of
Persistent becomes irrelevant in any project using SQL features specific
to the store (all of mines, what about yours Michael ?). That makes the
first two points not very convincing.

The third point does not make much sense to me. Here we spend a lot of
time designing efficient SQL schemas and migrations so that the store
stays fast and migrations are safe. That's not the kind of job that can
be automatically derived by a program by just looking at two models
descriptions.

Back to the feature of persistent raised by Greg, which is serializing
to and from the database with type-safety, I agree that this is
desirable.


On Mon, 13 Feb 2012 22:36:17 +0200, Michael Snoyman <michael at snoyman.com> s=
aid:

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

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

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

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

Michael> Michael

Michael> On Mon, Feb 13, 2012 at 9:53 PM, Paul R <paul.r.ml at gmail.com> wrot=
e:
>> 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=C3=A9 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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 :)
>>=20
>>=20
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.
>>=20
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.
>>=20
Greg> Greg Weber
>>=20
>> --
>> =C2=A0Paul
>>=20
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe

--=20
  Paul