Skip to content
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

Finish ppx integration #10

Closed
wants to merge 3 commits into from
Closed

Finish ppx integration #10

wants to merge 3 commits into from

Conversation

j0sh
Copy link
Contributor

@j0sh j0sh commented Dec 2, 2015

Tests now run and pass

@j0sh j0sh mentioned this pull request Dec 2, 2015
@foretspaisibles
Copy link
Contributor

How do you run the tests? I could contribute Travis CI integration. :)

BTW, since the project is called sqlexpr it is maybe a good idea to also use sqlexpr (instead of sql) to identify the extension point handled by the project. How do you see this?

@c-cube
Copy link
Contributor

c-cube commented Feb 21, 2016

I think it's ok to type [%sql instead of [%sqlexpr, verbosity is important. Apart from that I find this transition to ppx very nice, the tests look good too.

@mfp
Copy link
Owner

mfp commented Feb 22, 2016

I apologize for letting this aside for so long. I'm really swamped at the moment, but I'll try to take a look back at the ppx branch by the end of the week. IIRC it was essentially good to merge and the only thing missing relative to the camlp4 extension was sqlc statement hoisting? If I cannot see an obvious way to adapt that part from estring (my absolute lack of experience with ppx so far will likely get in the way) I'll probably merge as-is.

Also, [%sql is nice indeed. It's maybe an ambitious claim in the ppx namespace, but I don't anticipate anybody wanting to use 2 colliding extensions at once (the other ~SQL libs I can see on OPAM's repos are essentially alternative Sqlite3 libs, so it's one or the other, and PGOcaml, which AFAIK lacks a ppx extension but uses PGSQL in the camlp4 one)

@c-cube
Copy link
Contributor

c-cube commented Feb 22, 2016

It might be naive, but would it be possible to have [%sqlc "foo"] simply declare a toplevel value let stmt_37 = Sqlite3.prepare "foo";; and then replace the query with stmt_37?

I suppose the issue is that cached statements depend on the connection, so they cannot be totally static...?

@j0sh
Copy link
Contributor Author

j0sh commented Feb 22, 2016

The statement ID is generated and cached already with the [%sqlc ...] directive, unless estring does additional work that I'm missing? The ppx code in ppx_sqlexpr.ml is a fairly mechanical translation of pa_sql.ml, although I didn't look too much at what estring actually does.

@mfp
Copy link
Owner

mfp commented Feb 22, 2016

On Mon, Feb 22, 2016 at 03:38:57PM -0800, Simon Cruanes wrote:

It might be naive, but would it be possible to have [%sqlc "foo"] simply declare a toplevel value let stmt_37 = Sqlite3.prepare "foo";; and then replace the query with stmt_37?

I suppose the issue is that cached statements depend on the connection, so they cannot be totally static...?

In fact the statement cache is held by Sqlexpr's DB handle, the statement
carries an id used to retrieve the compiled statement from such cache.

estring essentially did the hoisting you showed in a more elegant way,
without exposing new bindings in the toplevel enviroment.

Anyway, the effect of moving the statement definition is limited, since IIRC
the only difference is the record not being allocated in the lexical site. So
in the end it comes down to 6 words not being allocated.

Mauricio Fernández

@mfp
Copy link
Owner

mfp commented Feb 23, 2016

On Mon, Feb 22, 2016 at 03:54:42PM -0800, Josh Allmann wrote:

The statement ID is generated and cached already with the [%sqlc ...]
directive, unless estring does additional work that I'm missing? The ppx
code in ppx_sqlexpr.ml is a fairly mechanical translation of pa_sql.ml,
although I didn't look too much at what estring actually does.

Yes, the actual caching is already there. The only extra thing estring does is
hoisting the record definition so that it's allocated statically when the
module is initialized. IOW just sparing 6 words worth of allocation for a
statement (O(params) for queries). I thought there was something else
involved, but after a quick look at the code that seems to be all there's to it.
I feel a bit silly now :)

Mauricio Fernández

@j0sh
Copy link
Contributor Author

j0sh commented Feb 23, 2016

The only extra thing estring does is
hoisting the record definition so that it's allocated statically when the
module is initialized.

Ah, I see it now -- the register_shared_expr line in pa_sql.ml. Missed that part. Will look at achieving a similar effect here, it would be an interesting exercise even if the benefit is marginal.

@mfp
Copy link
Owner

mfp commented Feb 28, 2016

hmm github got me scratching my head for a second, I just merged this into ppx and the latter into master, yet this is not detected as merged(?).

j0sh, are you still willing to do the shared expression thing? I've taken a look at ppx_sqlexpr.ml, parsetree.mli and ast_mapper.mli, and think I got the gist of how the AST mapping is done (keep in mind I haven't dabbled in ppx yet). So as a sign of atonement I can try to do it if you want :)

@j0sh
Copy link
Contributor Author

j0sh commented Mar 3, 2016

Hmm, seems that github only detects as merged when merging with the master/base branch.

WIP branch here for hosting shared expressions: #14

@j0sh j0sh closed this Mar 3, 2016
@mfp
Copy link
Owner

mfp commented Mar 6, 2016

On Wed, Mar 02, 2016 at 10:40:53PM -0800, Josh Allmann wrote:

Closed #10.

Thanks for all your great work, j0sh.

Mauricio Fernández

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants