Recommended DB layer?

I've seen yesod-persistent described as "worst practices", e.g. http://www.reddit.com/r/haskell/comments/1dk73s/web_frameworks_benchmark_4_i.... Is this just a one-off poster, or do others agree with it? What are considered best practices?

harry wrote:
I've seen yesod-persistent described as "worst practices", e.g. http://www.reddit.com/r/haskell/comments/1dk73s/web_frameworks_benchmark_4_i.... Is this just a one-off poster, or do others agree with it? What are considered best practices?
I am a very experienced programmer (20+ years of coding, doing Haskell since 2008) but had not done much with database before starting a project with Yesod and Persistent. Obvioulsy I don't really know what "best practices" are. 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. The only pain point has been breaking updates in the API causing me to have to fix my code. HTH, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

Erik de Castro Lopo
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.

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

Jeremy Shaw wrote:
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..
Queries written with Esqueleto support joins: http://hackage.haskell.org/packages/archive/esqueleto/latest/doc/html/Databa... in a relatively elegant way.
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.
It is my understanding that esqueleto only supports SQL databases Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

On Mon, Jun 17, 2013 at 6:36 AM, Erik de Castro Lopo
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.
It is my understanding that esqueleto only supports SQL databases
That's correct. Esqueleto is, and always will be, SQL-only. Its goal is to be as close to SQL as possible. Cheers, -- Felipe.

Jeremy Shaw
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..
I don't know how persistent is implemented, but the usual solution to a problem like that is that the capable backends will implement joins in SQL, while the others fake it in code.
participants (4)
-
Erik de Castro Lopo
-
Felipe Almeida Lessa
-
harry
-
Jeremy Shaw