-
Notifications
You must be signed in to change notification settings - Fork 237
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/support prepare statement #49
base: master
Are you sure you want to change the base?
Conversation
lib/resty/mysql.lua
Outdated
if self.state ~= STATE_CONNECTED then | ||
return nil, "cannot send query in the current context: " | ||
.. (self.state or "nil") | ||
end | ||
|
||
packet_type = packet_type or COM_QUERY |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can require packet_type
to be always defined, thus saving this branch.
it'll be more simple if we can store data on special cosocket object. for example: local ok, err = sock:set_bound_data(key, value)
local value, err = sock:fetch_bound_data(key) then we can store k-v like this: key: prepare_sql -- inside db:prepare(prepare_sql)
local statement_id = self.sock:fetch_bound_data(prepare_sql)
if statement_id then
return statement_id
end
... -- do prepare as current
self.sock:set_bound_data(prepare_sql, statement_id)
return statement_id @agentzh how about we take # attach arbitrary data to cosocket instances to ngx_lua_module? |
lib/resty/mysql.lua
Outdated
end | ||
|
||
|
||
local function _fetch_all_rows( self, res ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we already have Lua functions reading the result set. Can we reuse that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is, reusing the read_result
function and etc?
include: TINYINT, BIT, BOOL, SMALLINT, INT, INTEGER, BIGINT, FLOAT, DOUBLE, REAL, DECIMAL, DEC, NUMERIC .
Hello when will this be official release? |
Would love to know whether this one seems likely to get merged. |
This will definitely get merged at some point since this PR was the result of my request to @membphis :) He's been doing me a favor. |
Is there anything preventing this to merge? It would be cool to see it merged soon. |
Just for the record, we'll redo this atop a new OpenResty builtin API for better performance. We already use the new way to add preparing statement support for PostgreSQL. |
hello, when is added to the built-in function of this feature?? |
Are there any plans to complete this feature? |
hello, are there any plans to complete this feature? |
Really look forward the PREPARE statement support for MySQL. : ) |
do support mysql's prepare statement.
there are two ways for calling:
PS: It's not implement completely.