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

Convenience exec/query overloads that do parameterized SQL #118

Closed
Abscissa opened this issue Jun 30, 2017 · 7 comments
Closed

Convenience exec/query overloads that do parameterized SQL #118

Abscissa opened this issue Jun 30, 2017 · 7 comments

Comments

@Abscissa
Copy link

...using prepared statements behind-the scenes.

Ie:

conn.query("SELECT * FROM mytable WHERE id=? AND name=?", 7, "Frank")

@schveiguy
Copy link
Collaborator

schveiguy commented Jun 30, 2017

One other simple possibility is to expand the query and exec methods of PreparedImpl to allow one-line execution of sequences.

For example:

auto prep = conn.prepare("SELECT * FROM mytable WHERE id=? AND name=?");
foreach(r; prep.query(7, "Frank")) { ... }

If you do go for the one liner, one thing that the current implementation makes a bit cumbersome is that you have to store the Prepared somewhere while you iterate, or it will try to purge the result and release the prepared statement (this is how I came across #117). The way I solved it is to create a wrapper struct that holds both the Prepared struct and the ResultRange, and I alias this the range. Of course, if you mitigate that in ways that we discussed in that issue, it may make things much nicer.

@Abscissa Abscissa added this to the v1.2.1 milestone Dec 12, 2017
@Abscissa Abscissa modified the milestones: v2.0.0, v2.1.0 Jan 30, 2018
@quickfur
Copy link

FWIW, in my NIH version of sqlite.d, I just use RefCounted on the prepared statement (which in turn holds a reference to a RefCounted database handle) so that I don't have to worry about keeping track of who's referencing what, where, and when they will be done. I just let the refcounting do its job. :-P

@Abscissa
Copy link
Author

FWIW, The refcoutning problem @schveiguy refers to above was fixed in v1.1.4 (see second-to-last bullet item under v1.4.4)

@Abscissa
Copy link
Author

Abscissa commented Feb 9, 2018

Added in branch "v2.1.x" via 7a8fc46, e793af7, and 35cddc8

@Abscissa Abscissa closed this as completed Feb 9, 2018
@schveiguy
Copy link
Collaborator

Nice. I may be able to just about eliminate my templates that do this :)

@schveiguy
Copy link
Collaborator

I have to come back here to say, was able to trim out ALL of my cruft in my DB wrapper. Things in mysql-native are looking awesome!

  • I no longer need Refcounted wrapper structs
  • I no longer need these convenience wrappers (I simply had to rename my fetch calls to query, and things worked seamlessly, and I had already named my non-data-returning function exec, so no changes needed there).
  • I no longer have extra scopes to ensure ref counting does the "right thing". Things just work.

I was able to delete probably about 130 lines of code from my project that just dealt with wrapping and lifetime. Kudos!

@Abscissa
Copy link
Author

Glad to hear it!

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

No branches or pull requests

3 participants