-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ppx syntax extensions #9
Comments
AFAIK, there's no one actively working on this. It would be of course welcome, but it's low priority for now. |
Just a gentle ping to get an update on this? Is there anybody known to be working on such extensions? I thought I once read about it for a few weeks but I cannot find the reference again. |
I don't know of anybody working on such extensions. It's on my TODO list, but it has a fairly low priority since Camlp4 is still supported. |
A nice side-effect of switching is that presumably we'd get Merlin support "for free", as far as I can tell? |
Hi, I ported the syntax extension to ppx. The tree is available at: https://github.com/eras/pgocaml/tree/ppx . I did it to learn ppx, so there might be some issues left :). I think there might be issues with the "execute" feature, plus I'm not all sure the _oasis is properly configured for ppx, but all in all it seems pretty complete.. It is still work in progress, though. The syntax is: [%pgsql dbh "sql here"]. Bonus: it indeed seems to work fine with Merlin! |
@eras: Awesome! I'm a bit short on time to play with this right now, but I'll gladly merge any PR once you're satisfied with it... There is one extra feature which might be worth considering for a PPX extension: for many SQL statements (most other than SELECT, in fact) we don't really care about the return value. I though it would be useful to have a variant of |
@eras Thank you for doing this! :) |
Hi. |
Yes, it's something I'd like to do sooner rather than later. There's just a fair bit on my plate right now... |
I have been playing with @eras syntax extension using ppx ( I haven't used it for anything serious yet, just toy programs to see if it works), and except for some merlin issues related to Description of the issue: Lets say I have an "execute" After that, I add a bunch of queries (using the This can be reproduced easily if you open the
This issue may also happen in the camlp4 version, but since it doesn't work with merlin I don't really know. What I know is that the translation seems quite direct when looking at the diffs so this behavior is probably shared by the two implementations of the syntax extension.
Doesn't that happen automatically already based on what the query itself returns? I get |
Ok, I found what causes this. The ppx extension removes the connection if an exception is raisen (the camlp4 doesn't) https://github.com/eras/pgocaml/blob/ppx/ppx/ppx_pgsql.ml#L435-L438 I don't know why doing so is necessary in the ppx extension (maybe it isn't). Anyway, I modified my local version to stop doing that and now it works as expected. Edit: here is the reason eras@b51021a @eras so far I'm not having this problem, do you remember when did it happen to you? I would like to know how to reproduce it. |
Ok, think I know why it doesn't happen to me. My local copy is in sync with If anyone wants to give it a try just pin this repo and reinstall pgocaml:
Your |
I have been using it more in the last days (from https://github.com/tizoc/pgocaml#ppx-ocaml403 since I upgraded to OCaml 4.03 and the ppx extension had to be updated, that branch also includes a few other changes like handling of enums as if they were strings). Something I think can be improved is for the syntax to not take the database handle parameter, and instead just produce a one argument function, that takes the database handle, and then runs the query at that moment. Something like this: (* query : ('a PGOCaml.t -> 'b PGOCaml.monad) -> 'b PGOCaml.monad *)
let query = {pgsql| SELECT name, age FROM people |pgsql} in
let%lwt dbh = connect_to_db () in
let%lwt rows = query dbh in
(* ... *) This kind of syntax doesn't handle the extra flags that the current syntax support (more importantly, "execute" and "nullable-results", not sure what the best way to do that would be). Anyway, I haven't experimented with that yet, just sharing my thoughts for now. |
Hi, Sorry for not being more active about this project. It wouldn't require that much to finish it I think.. Also thanks for the detective work on how the connection syncing was introduced. But one thing holding me back is that there could indeed be a nicer syntax for the ppx. The one you suggest seem infact nicer than any of the ones I thought of! Though as you mention, there should still be a way to handle those additional options. I had some ideas but have since forgotten them :). One thing I was hoping would be a way to embed strings in such a way that they could be constructed by other PPX modules, allowing constructing queries with macros from fragments, even if truly building queries runtime from fragments is not possible. For example user-controllable sorting would basically require something like that. But I suppose this is not a priority, it's enough to get this out of the door so people can rejoice the cool PPX functionality with Merlin ;-). |
There was a similar request posed for sqlexpr recently, here's a good answer: mfp/ocaml-sqlexpr#18 (comment) Nice job on the ppx conversion, @eras. Would be nice if some of the WIP commits could be squashed together for easier review? |
@j0sh you can see the changes all combined in one diff here master...eras:ppx But what you probably want to do is diff the files implementing the ppx and camlp4 extensions (because @eras didn't really modify the existing code, he wrote a new file containing a port from camlp4 to ppx). |
For anyone interested, I made a new ppx extension that I have been using lately and has worked pretty well so far. I haven't uploaded it anywhere yet but will probably do so soon. It looks like this: let update =
{sql|
UPDATE accounts
SET email = $email, account_type = $account_type
WHERE account_id = $account_id
RETURNING account_id, created_at, account_type, email
|sql} it returns a labelled function (with one label per argument name, and optional argument labels for parameters marked as optional with email:string ->
account_type:string ->
account_id:int64 ->
(string, bool) Hashtbl.t Pg_store_helpers.PGOCaml.t ->
(int64 * CalendarLib.Calendar.t * string * string) list
PGOCaml.monad Like the camlp4 extension it connects to the database to figure out the types of columns and validity of queries. It doesn't support the execution of queries at compile time, and there there is no way to configure the connection, I may add that later. |
@eras thanks for ppx. Good job! |
@zbroyar thats up to @darioteixeira. I haven't been using @eras' ppx extension myself, but my own instead. It is different, and doesn't contain the same features, I just did the minimium required for my use cases. I have been using it for months already without issues. I just pushed it to github, you can find it here: https://github.com/tizoc/ppx_pgsql |
These forks look like great starts but it's difficult to use them without them being on opam. Is there a plan to merge either into the current pgocaml repository or publish them separately to opam? The problem I'm encountering specifically is helping a project that uses pgocaml to be able to use reason syntax as well, which doesn't support camlp4. |
@charlesetc you can pin ppx_pgsql and it will be installable through opam:
|
I can merge the PPX into PG'OCaml if the general feeling is that it works and is stable... |
For what it's worth, here's a branch based off @eras's nice ppx work, compared against pgocaml master here. https://github.com/darioteixeira/pgocaml/compare/master...j0sh:ppx?expand=1 Haven't done a lot of testing myself yet other than running the preexisting tests. More context here: eras#1
|
There's more than one branch in discussion here. I'll merge one which a) supports the killer-feature of the existing Camlp4 extension (compile-time type-checking against the DB), b) has users, c) applies cleanly against master. @tizoc: I personally don't use compile-time execution of queries (in contrast with compile-time type-checking), but I reckon some users may rely on that feature and will be upset if it's dropped... @eras and @j0sh: I'll merge whichever branch you guys agree on for merging. Hash it out between you and tell me which one I should review... |
My ppx extension is also a bit different from the original one (in a way that I like more, thats why I wrote it), so even if it supported compile-time execution (something that can be added), it is probably not the syntax extension current users of the camlp4 extension would expect. I have been using it for a good amount of time already without problems (even since before I pushed it to Github), but it is just an alternative, I didn't meant for it to be merged back into pgocaml. |
If I can add a little bit of noise on this PR just to say that I most definitely rely on the |
I'd understand completely if something like @tizoc's branch can't be merged - is there a way to pin a dependency like ppx_pgsql to a git repository in an OPAM file? |
I've made a couple of minor changes on top of @j0sh 's work, with the most relevant being some use documentation in the readme and a slight refactoring of how PG'OCaml handles connections to Postgres (rather, to how PG'OCaml handles information about potential connections) in order to provide more informative error messages on connection failures. |
I have just merged @chrismamo1's PR #56 (and #57) which implements full PPX support. It has been tested reasonably well and will be continued to be tested (as it is used in a fairly large project). After some more testing I will soon release a version with PPX support on opam. |
Is this planned or being worked on?
The text was updated successfully, but these errors were encountered: