command function which allows you to efficiently fetch number of rows affected (postgresql “command tag”). Thanks to @akheron for suggestion / research and help.
You can now use nested tuples in queries and not only predefined Database.Postgresql.Row* types.
Extended example in README.md . We are processing README.md file using literate-purescript (by @thimoteus) and incorporate this example into our test suite so it should be always up to date.
What’s next:
We want to improve error handling - there is ongoing discussion on the topic in the issue section.
We want to build on top of this lib proper Selda port as proof of concept library (https://github.com/paluh/purescript-little-selda) already exists and shows that we can use just records instead of “inductive tuples” in PureScript land. We have scheduled work for this task already and we hope to deliver something production ready in the next four months.
I want to prototype a PureScript tool which will replace sqltopurs and be able to use corefn to extract sql statements and validate their Query type against postgresql as it is done in sqltopurs. Instead of code generation we want to provide easier to use “type checker”. No timeline yet.
I’m curious how the README is moved to the tests directory with literate-purescript. It looks like there are extra helper functions in the Test.Main module beyond what’s included in the README – mind sharing a little about how that’s done?
Most of my projects are UI-focused, so there’s not really an opportunity to leverage this, but I’d love to hear more about the approach.
One important note about format of the README file:
litps (its lierate-purescript command) takes your *.md file and searches for all purescript code sections which starts without any indentation.
It extracts them and moves them to the final module.
If you want to have some PureScript code snippets in README which should not be a part of generated module you can just indent them and litps will ignore these sections.
Here is an example which contains code snippets above Example sections which are not incorporated into resulting file because they are indented in the markdown source: https://github.com/paluh/purescript-redis-hotqueue
This indentations are ignored by markdown interpreters on pursuit and on github so the HTML output is still nice
Hi! @RAbraham this is really good question but I probably should not answer it as I’m going to be biased for sure… But anyway…
The main difference for me is the query type. In purescript-postgresql-nodeQuery is parametrized over output type but in purescript-postgresql-client it is parameterized over input and output types.
If you are working only on the layer of String queries which are executed “right away” you can easily ignore this difference.
It can start to be somewhat important when you are building your queries separately from their execution. In such a case I think it is better to be able to provide input and output types for your query because compiler will check if input values “are correct” on the query call site.
On the other hand you can say that all these String queries types are “assigned by hand” so they are not really relevant…
But if you think about type checked SQL queries this can make a big difference.
Design of two paramaters Query was chosen by @rightfold from the beginning.
Later she had also provided sqltopurs PS codegen tool which produces correctly typed Query values. They are type checked against postgresql database. In this context both parameters of a Query are checked and saved in generated PS code.
@Kamirus has just started new project in which he is exploring design space for selda port (https://github.com/Kamirus/purescript-selda) and this structure of Query type is important in this context too. This future Selda DSL (hopefully even nicer than Haskell version) will produce SQL Query values correctly typed over input and output types.
The last and probably minor point is that postgresql-client, because of these bidirectional Query type, provides two complementary type classes ToSqlValue and FromSqlValue for which we can provide some “law”: identity = toSqlValue >>> fromSqlValue.
So in some sens these are “lawfull” type classes
I want to refactor this library and I wonder if anybody uses “tagless / mtl” helpers from PG module - from my perspective they introduce more confusion than value. I want to drop them and leave only plain Aff layer. If you have an opinion there is [a dedicated issue here].
