On Mon, Feb 13, 2012 at 11:52, Greg Weber g...@gregweber.info wrote:
That being said, I would like to have a Template Haskell interface
instead of just a QQ interface. The reason why we haven't bothered
with doing that ourselves is because the record name-spacing issue
makes the current QQ
Hi Deian,
Thanks for bringing this to our attention - this is a neat project! It
actually looks *exactly* like persistent - I can't actually discern a
meaningful difference, although likely your internals are slightly
simpler if you only support MongoDB. If your goals are to support
multiple
Hi Greg,
Thanks for bringing this to our attention - this is a neat project! It
actually looks *exactly* like persistent - I can't actually discern a
meaningful difference, although likely your internals are slightly
simpler if you only support MongoDB. If your goals are to support
multiple
Hi Sergiu,
Thanks you for your interest in that proposal. I rushed it off a year
ago. Since then we have made a lot of improvements to Persistent and
the library forms a basic building block for most Yesod users and
other Haskellers. Persistent offers a level of type-safety and
convenience not
With respect, I don't think that Persistent is a natural choice
as the go-to tool for Haskell users, simply because it requires
knowledge of a lot of Yesod-EDSL syntax.
The set of users with persistent data needs seems a very
different set than that of those who are familiar with Yesod,
Actually, Persistent is fully usable without any special syntax, DSLs,
or Template Haskell. In fact, Persistent itself has no
template-haskell dependencies, specifically so that it can be built on
ghc-iphone. Additionally, the Persistent DSL syntax is completely
separate from any other Yesod DSL
It seems that all tutorials and resources for Persistent use Template
Haskell along with several Yesod specifics.
But, I could be wrong, or new tutorials could be written.
Tom
On 2/13/12, Michael Snoyman mich...@snoyman.com wrote:
Actually, Persistent is fully usable without any special
Persistent is a database abstraction layer with no dependencies on
Yesod. Those that need a persistence layer have the same needs to
interface with the database in a type-safe way, regardless of whether
their program presents a web interface.
Have you tried using Persistent? We have never heard a
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
On Mon, Feb 13, 2012 at 9:01 PM, Greg Weber g...@gregweber.info wrote:
Thanks you for your interest in that proposal. I rushed it off a year
ago. Since then we have made a lot of improvements to Persistent and
the library forms a basic building block for most Yesod users and
other Haskellers.
On 2/13/12, Paul R paul.r...@gmail.com wrote:
[...]
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
On Mon, Feb 13, 2012 at 9:53 PM, Paul R paul.r...@gmail.com wrote:
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,
For one, I am adverse to DSL based on quasi-quotation. Not because
I find the syntax hard - to be honnest it is often the opposite, with
DSL designed with ease of use in mind - but because of the volatile
nature of languages without specification, be them basic DSL. It is
quiet hard to settle on a
On 2/13/12, Sergiu Ivanov unlimitedscol...@gmail.com wrote:
[...]
a stable, flexible, and
easy-to-work-with, already existing storage interface should allow
Haskell programmers to focus less on IO and more on the purely
functional logic.
+1 - Very exciting!
Tom
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.
Tom Limited /= Worst,
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
Paul, I appreciate your experience and you might find it interesting
that I have come to similar conclusions from my own experience!
As Tom commented though, just because something is limited does not
mean it is bad for every project. There are many small scale projects
that do just fine with
Hello Michael,
From Persistent documentation :
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
This proposal is vague and we would need to work with you to narrow
things down a bit.
Yes, that would be cool :-) Since I'm not familiar with Persistence at
all (unfortunately :-( ), do you have some suggestions for me to start
with?
I've found this http://www.yesodweb.com/book/persistent
On 02/13/2012 09:36 PM, Michael Snoyman wrote:
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
20 matches
Mail list logo
