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/support prepare statement #49

Open
wants to merge 30 commits into
base: master
Choose a base branch
from

Conversation

membphis
Copy link

do support mysql's prepare statement.

there are two ways for calling:

-- first way
mysql:new
db:connect
db:run

-- another way
mysql:new
db:connect
db:prepare
db:execute
db:set_keepalive

PS: It's not implement completely.

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
Copy link
Member

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.

@membphis
Copy link
Author

membphis commented Aug 17, 2016

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
value: statement_id

-- 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?

end


local function _fetch_all_rows( self, res )
Copy link
Member

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?

Copy link
Member

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?

@tmiskoEconomia
Copy link

Hello when will this be official release?

@forkfork
Copy link

Would love to know whether this one seems likely to get merged.

@agentzh
Copy link
Member

agentzh commented Mar 24, 2017

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.

@denisu
Copy link

denisu commented Nov 13, 2018

Is there anything preventing this to merge? It would be cool to see it merged soon.

@agentzh
Copy link
Member

agentzh commented Feb 5, 2019

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.

@yukixia
Copy link

yukixia commented Aug 27, 2019

hello, when is added to the built-in function of this feature??

@nafey
Copy link

nafey commented Oct 4, 2020

Are there any plans to complete this feature?

@vinsonzou
Copy link

hello, are there any plans to complete this feature?

@sunlin7
Copy link

sunlin7 commented Jul 14, 2021

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.

Really look forward the PREPARE statement support for MySQL. : )

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.

None yet

10 participants