
I have not looked at persistent in AGES. So, my information is horribly out
of date. But I think the issue with 'lowest common denominator' is that it
means you can not exploit the useful power of the underlying database. For
example, I believe that at one point in time (no idea about right now),
persistent could not do SQL-level joins -- because not all backends could
support joins..
Now, for a vast majority of websites, that is not an issue -- because most
websites are lucky to get hundreds of hits *per day*. So, making it easier
to implement bug free code is a huge win! But, if you care a lot about
performance, then that could be a problem.
If persistent aims to be able to target wildly different backends, some of
which are not even SQL based, then it seems like it would hard for it to
also have optimal performance. Though, good enough performance for most
people is quite obtainable.
There are, of course, many other attempts to bring type-safe to database in
Haskell. Ranging from things that bind to SQL, like haskelldb, to native
persistance layers like acid-state. They all have their strengths and
weaknesses.
- jeremy
On Mon, Jun 17, 2013 at 2:02 AM, harry
Erik de Castro Lopo
writes: However, I have found Persistent along with Esqueleto a most pleasant experience. My app is only targeting Postgresql. I did some reading on database design, specifically about the importance of normailizing the data. I then designed the the schema and started writing inserts (using Persistent) and queries and updates (using Esqueleto). I am 100% certain that the type safety these languages of these interfaces has prevented numerous bugs.
Thanks for the heads up, I should give Esqueleto a look. The "lowest common denominator" complaint did seem a bit strange to me, because it's exactly what I'm used to doing in LINQ.
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners