Skip to content

Feature/support prepare statement#49

Open
membphis wants to merge 30 commits intoopenresty:masterfrom
iresty:feature/prepare_statement
Open

Feature/support prepare statement#49
membphis wants to merge 30 commits intoopenresty:masterfrom
iresty:feature/prepare_statement

Conversation

@membphis
Copy link
Copy Markdown

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.

Comment thread lib/resty/mysql.lua Outdated
.. (self.state or "nil")
end

packet_type = packet_type or COM_QUERY
Copy link
Copy Markdown
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
Copy Markdown
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?

Comment thread lib/resty/mysql.lua Outdated
end


local function _fetch_all_rows( self, res )
Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown

Hello when will this be official release?

@forkfork
Copy link
Copy Markdown

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

@agentzh
Copy link
Copy Markdown
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
Copy Markdown

denisu commented Nov 13, 2018

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

@agentzh
Copy link
Copy Markdown
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
Copy Markdown

yukixia commented Aug 27, 2019

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

@nafey
Copy link
Copy Markdown

nafey commented Oct 4, 2020

Are there any plans to complete this feature?

@vinsonzou
Copy link
Copy Markdown

hello, are there any plans to complete this feature?

@sunlin7
Copy link
Copy Markdown

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.

10 participants