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

Feature: executeMulti #75

Closed
lteacher opened this issue May 10, 2016 · 3 comments
Closed

Feature: executeMulti #75

lteacher opened this issue May 10, 2016 · 3 comments

Comments

@lteacher
Copy link

Hello,

There was some reference in an unrelated issue #24 to an idea of having the executeMulti or similar. Was there any further thought or development on that idea? Maybe i missed it somewhere or its not documented, however, it seems useful. The sqljocky does have this and it would be beneficial for me to have it so I wanted to ask here.

For clarity the suggestion is, some method like executeMulti that can do List<List> or List<Map> e.g.

executeMulti('insert into my_table values (@a, @b, @c)', [
  {"a": 1, "b": 2, "c": 3},
  {"a": 4, "b": 5, "c": 6},
  {"a": 7, "b": 8, "c": 9},
]))

// And (if i have this syntax correct...)
executeMulti('insert into my_table values (@0, @1, @2)', [
  [1, 2, 3],
  [4, 5, 6],
  [7, 8, 9],
]))
lteacher added a commit to lteacher/dart_postgresql that referenced this issue May 10, 2016
Added `executeMulti` and decided to add `queryMulti` as well because
some people might want to use the insert returning form and that
needs the `query` not `execute`
@lteacher
Copy link
Author

Obviously I implemented in fork per above awaiting any replies for this one.

lteacher added a commit to lteacher/shellstone that referenced this issue May 11, 2016
Implements the `@n` syntax, uses `[query|execute]Multi` though
so it depends on feature in xxgreg/dart_postgresql#75
@xxgreg
Copy link
Owner

xxgreg commented May 16, 2016

Apologies - I am totally snowed under at the moment. I'd recommend implementing executeMulti in a separate package for now.

Given the simple query protocol that this driver uses there isn't a performance benefit to baking this into the existing library. So the main concern is the user API, which in most cases I imagine will be some kind of ORM.

For this library I am willing to help with bug fixes, but not really planning on adding new features for the time being.

@lteacher
Copy link
Author

Hi @xxgreg

I understand. You are correct I am working on an ORM implementation and indeed there is no performance improvement that I can imagine, its only the api. In saying that per your comments I did implement the feature I believe to an acceptable standard.

I am depending on the fork at the moment. Maybe I can just create the pull request, you could then reject or review when you have time its up to you. Of course I would prefer to depend on this package directly rather than having some split.

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

No branches or pull requests

2 participants