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 <voldermort@hotmail.com> wrote:
Erik de Castro Lopo <mle+hs <at> mega-nerd.com> 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