Open
Description
I'm submitting a...
- Bug reportFeature requestQuestion
Current behavior
When created a stored procedure it's necessary to change the delimiter
e.g. DELIMITER $$
However, when using a SQL-file it returns ER_PARSE_ERROR:
Expected behavior
Be able to change the delimiter, create the SP and return delimiter back to standard ;
Minimal reproduction of the problem with instructions
DELIMITER //
CREATE PROCEDURE testProc()
BEGIN
SELECT 1;
END //
DELIMITER ;
What is the motivation / use case for changing the behavior?
Cannot create or migrate stored procedures
Environment
db-migrate version: 0.11.5
db-migrate-mysql with versions: 1.1.10
Additional information:
- Node version: 8.12.0
- Platform: Mac
Others:
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
Activity
wzrdtales commentedon Jun 1, 2019
I have to push that through, to the upstream driver https://github.com/mysqljs/mysql. Can you try and verify it is possible to store a stored procedure with the raw driver?
wzrdtales commentedon Jun 1, 2019
Quick issue dig gives this mysqljs/mysql#1683 . So upstream issue.
wzrdtales commentedon Jun 1, 2019
Respectively, read this comment mysqljs/mysql#1683 (comment)
wzrdtales commentedon Jun 1, 2019
So setting multipleStatements to
false
will allow you to do this.DELIMITER
needs to removed completely since it is not SQL either.What will be possible in some future (don't know yet when I will do it). There is a concurrency manager planned. For this I will need to spawn multiple connections and instances of the driver. On that way down I could give that freedom down to the migration, to spawn a different connection with different settings. So you could selectively disable
multipleStatements
. However, it would be clearly out of scope to implement a full fledged sql parsers, for a shit ton of different SQL dialects, so this problem is unfortunately unique to the MySQL driver. Not sure actually how for example the pg driver behaves on that.tabroughton commentedon Jun 1, 2020
hi @wzrdtales I was also testing out db-migrate and would have liked to be able to create store procedures, triggers etc all of which require adding a delimiter into the sql statement (create procedure etc). I also need
multipleStatements
. I understand the comments upstream that mysqljs/mysql is an implementation of the mysql spec and DELIMITER is a feature of the CLI. I suppose it won't become a feature upstream. However, I think that like the CLI implementation other interfaces could implement something and in that thread I see somebody has created what looks to be quite thorough implementation of the capability mysqljs/mysql#1683 (comment)I was wondering if this (approach) might be a good feature to incorporate into db-migrate
tabroughton commentedon Jun 1, 2020
After a few tests I don't think this is an issue at all as I have been able to create stored procedures with multipleStatements true in my connection config. I am using sql files and a lot of them have multiple statements, I only need separate sql files for the create procedure statements and for those files to contain a single statement but mixed in this is fine for me.
tabroughton commentedon Jun 1, 2020
after further tests I can see that this isn't actually an issue for me at all. I have my connection config set to
multipleStatements
true
and can indeed run multiple statements with stored procedures in the same sql file such as this one:no need for a delimiter change at all
munawarb commentedon Jun 28, 2020
@tabroughton Thanks for checking into this and experimenting with it. I had the same issue then came across your comment saying to remove the delimiter settings. With multiple statements set to true, this works when adding stored functions and procedures.
lasergoat commentedon Aug 7, 2020
using mysql
I can confirm, with
multipleStatements
set to true in the database.json and no delimiters, I was able to have a migration like:PaulVipond commentedon Aug 16, 2022
But what you can't do is:
I.e. multiple procs within the same text string.
wzrdtales commentedon Aug 17, 2022
well you shouldn't a single run sql should be a single operation
PaulVipond commentedon Aug 23, 2022
I respect your opinion, but disagree :-) For me, migrations are there to support features that are being added to the database. If the feature requires 2, 3 or 4 stored procedures, then I would like to include them in the same migration. I understand we can't do that currently, though we worked round this by changing the generated javascript file to parse the 'up' sql file and create the stored procs in blocks.
wzrdtales commentedon Aug 23, 2022
that is fine, you can include them in the same migration, just not in the same operation. Operations should be atomic and not clunched together. If you want to do this and lunch everything in a single command I don't know why you use a migration frameworks specific API for controlled atomic migrations instead of just executing SQL files (which this migration framework can do as well, just not that beautiful yet).