I currently have all of my sql queries written in my PHP files, within each class method. Is it possible to move all of these queries into stored procedures or stored functions in the database & simply pass the corresponding values / arguments into them from PHP?
I have read some of the documentation & it still appears unclear.
Thank you. :)
DELIMITER $$
create procedure `accounting`.`delete_invoice_line` (invoice_line_id INT)
BEGIN
delete from invoice_line where id = invoice_line_id;
END;
$$
DELIMITER ;
I had to figure the format for creating the procedure. I am following this pattern & it appears to be working properly. Then granting execute privileges for the user name.
Thank you all for your input. :)
Most queries can be moved into stored procedures, but probably not all of them. See mariadb's documentation on which SQL statements cannot be used in stored procedures:
ALTER VIEW; you can use CREATE OR REPLACE VIEW instead. LOAD DATA and
LOAD TABLE. INSERT DELAYED is permitted, but the statement is handled
as a regular INSERT.
LOCK TABLES and UNLOCK TABLES.
References to local variables within prepared statements inside a stored routine (use user-defined variables instead).
BEGIN (WORK) is treated as the beginning of a BEGIN END block, not a transaction, so START TRANSACTION needs to be used instead.
The number of permitted
recursive calls is limited to max_sp_recursion_depth. If this variable
is 0 (default), recursivity is disabled. The limit does not apply to
stored functions.
Most statements that are not permitted in prepared
statements are not permitted in stored programs. See Prepare
Statement:Permitted statements for a list of statements that can be
used.
SIGNAL, RESIGNAL and GET DIAGNOSTICS are exceptions, and may be
used in stored routines
Having said this, even though a SQL statement can be moved into a stored procedure, you may not necessarily want to do that due to code complexity or performance reasons.
Related
I need to use user variable in prepare statement of mysql
stored procedure. (The purpose is to substitute the table name in
drop table command, which is unable to be injected via ? and
passed via execute using... statement because it is not a data element).
I suppose the user variables are session-wide global variables.
I suppose the stored procedure accessing the user variable must be
synchronized to protect against unwanted behaviour when it is called
simultaneously more times within single session (which I cannot prevent).
How to perform such synchronization?
Is there any chance it is performed internally by the mysql?
It seems like mysql get_lock() & co. uses logic that does not help much:
get_lock('a') followed by get_lock('b') destroys state of a. Maybe I have terribly missed some point here...
For those who would ask the "what exactly would you like to do" question:
drop procedure if exists drop_t_table; delimiter $$
create procedure drop_t_table(in in_t_table_name varchar(128))
begin
declare sql_drop varchar(256) default 'drop temporary table if exists ';
--
-- I would suspect sql_drop_table user variable guard should be locked here...
--
set #sql_drop_table = concat(sql_drop, in_t_table_name);
--
-- What if the procedure is preempted to another call here
-- and the sql_drop_table gets different table name?
--
prepare exe from #sql_drop_table;
--
-- ...and unlocked here
--
execute exe;
deallocate prepare exe;
end$$ delimiter ;
Variables declared within your stored procedure are local to the procedure. An example is sql_drop in your code.
Each session is, basically, single-threaded. You can't do more than one thing at a time within a session. There's no way to call a stored procedure more than once from within a particular session.
If you have more than one session you can call the same stored procedure from both of them. But, a DROP TABLE operation is basically idempotent: If you call it more than once, it has the same effect as calling it just once. It isn't precisely idempotent: it throws an error if the table doesn't exist. But, still, dropping the same table more than once isn't any more destructive than dropping it once.
Temporary tables (a) are only visible to the session that created them, and (b) vanish when the session ends. So, going to a lot of trouble to drop them explicitly might be overkill.
So, with respect, you might be overthinking this problem.
I have execute only access to a stored procedure.
This SP seems to select some data from multiple tables, and returns one row. I need to store two columns of the output of this SP into a table.
Is there any way to do this within MySQL?
If it returns a row, this is a stored function and not a stored procedure. You can use something like the following to insert into your table:
INSERT INTO tablename SELECT (SELECT col1, col2 FROM (SELECT somefunction()))
Otherwise, it will be a stored procedure and you should do something like this, assuming that #var1 and #var2 are output parameters:
CALL someprocedure(#var1, #var2, #var3)
INSERT INTO tablename SELECT(#var1, #var2)
See the documentation about Create Procedure and Create Function for more information about functions versus procedures.
MySQL has an extension to stored procedures that allows the procedure to return one or more result sets to the client, as if the client had issued a SELECT query... but those results are ephemeral. They don't persist and they can't be stored in variables or otherwise accessed after the procedure finishes -- they can only be "fetched" the one time.
There is a way to make them accessible without breaking the way the procedure already works, as I discussed here, but you can't do it without a change to the procedure:
How to use Table output from stored MYSQL Procedure
The idea is for the procedure to write its output in a temporary table, and then return it to the caller by calling SELECT against the temporary table -- but to leave the temporary table behind so that the caller can access it directly if desired.
That's not exactly the same as what you're asking though, which is why I didn't mark this question as a duplicate, since you, unlike the other poster, do not appear to have administrative control of the procedure... but unless you can make the case for a change like this, there's not another way within MySQL to access those returned values, since they only exist in the result-set that's returned.
Of course, procedures do have optional OUT parameters, where you can hand variables to the procedure as part of arguments you use to call it, and it can set those variables, so that they'll have the values you need when the procedure is done, but that only works when the return values are scalars and would require a change to the procedure's interface, since procs in MySQL do not have "optional" arguments... if the procedure were changed to permit this, it would require an increased number of arguments to be provided every time it was called, and if other components are calling it, that could easily break other things.
I know that in triggers you have the keywords NEW and OLD to refer to the entry that is being, or was, inserted into the table to which the trigger is bound. Are there any other keywords? I'm looking for one specifically that reference's the table that the trigger is bound to (like CUR_TABLE, or something); this way I can copy the trigger and apply it to several tables with different names and not need to alter the body of the trigger? Thanks in advance for any help!
Dynamic SQL cannot be used in triggers. For the trigger to exist, then the developer already knows what table he's in - so the table name should theoretically be hard coded.
If you are generating triggers, from say a stored procedure, you can generate them with variable table names - but cannot execute them (so you would have to take the result of the stored procedure and execute it separately).
See: http://dev.mysql.com/doc/refman/5.6/en/stored-program-restrictions.html
SQL prepared statements (PREPARE, EXECUTE, DEALLOCATE PREPARE) can be used in stored procedures, but not stored functions or triggers. Thus, stored functions and triggers cannot use dynamic SQL (where you construct statements as strings and then execute them).
This is not possible in MySQL. You may do a small PHP script that generates the code for each "table name" in an array :)
I have a procedure that creates a table, is it possible to have a view (or similar) that can call the procedure then select from the table?
I've tried this:
DELIMITER $$
CREATE DEFINER=`root`#`localhost` FUNCTION `new_routine`(p1 INT) RETURNS int(1)
BEGIN
CALL rMergeDateFields();
RETURN 1;
END
CREATE VIEW `db`.`vIntervals` AS
SELECT new_routine(0) AS col1;
SELECT * FROM MergedData;
but I get this error
Error 1422: Explicit or implicit commit is not allowed in stored function or trigger.
Any ideas?
No, you cannot. Views are typically read-only operations; and that behavior cannot be guaranteed if stored-procedures are invoked.
Related question:
How to call Stored Procedure in a View?
Is it possible to call stored procedure in view?
Here is a canonical resource:
http://dev.mysql.com/doc/refman/5.1/en/view-updatability.html
Some views are updatable. That is, you can use them in statements such as UPDATE, DELETE, or INSERT to update the contents of the underlying table. For a view to be updatable, there must be a one-to-one relationship between the rows in the view and the rows in the underlying table. There are also certain other constructs that make a view nonupdatable.
As invoking the stored procedure cannot assure 1:1 relationships with view rows, the update is not permitted.
You can't do this from a view, but a stored procedure itself can return a result set.
DELIMITER $$
CREATE DEFINER=`root`#`localhost` PROCEDURE `merge_and_select` ()
BEGIN
CALL rMergeDateFields();
SELECT * FROM MergeData;
END $$
If you CALL merge_and_select() the rMergeDateFields procedure will be run and then you will get the contents of the MergeData table returned to you, in one step... which sounds like what you're wanting.
This is, however, a really bad implementation, because there's no control for concurrent calls to merge_and_select(), so all kinds of things could go wrong if it's run more than once at the same time.
However, depending on what you really need rMergeDateFields() to do, it's possible that you could rewrite rMergeDateFields() to actually perform whatever work you need done and return it directly to the client without using the MergeData table using an unbounded SELECT, as shown above.
Anything you SELECT in a stored procedure without using INTO a variable is returned to the client as a response from the CALL.
I'm looking at MySQL stored procedures and functions. What is the real difference?
They seem to be similar, but a function has more limitations.
I'm likely wrong, but it seems a stored procedure can do everything and more than a stored function can. Why/when would I use a procedure vs a function?
The most general difference between procedures and functions is that they are invoked differently and for different purposes:
A procedure does not return a value. Instead, it is invoked with a CALL statement to perform an operation such as modifying a table or processing retrieved records.
A function is invoked within an expression and returns a single value directly to the caller to be used in the expression.
You cannot invoke a function with a CALL statement, nor can you invoke a procedure in an expression.
Syntax for routine creation differs somewhat for procedures and functions:
Procedure parameters can be defined as input-only, output-only, or both. This means that a procedure can pass values back to the caller by using output parameters. These values can be accessed in statements that follow the CALL statement. Functions have only input parameters. As a result, although both procedures and functions can have parameters, procedure parameter declaration differs from that for functions.
Functions return value, so there must be a RETURNS clause in a function definition to indicate the data type of the return value. Also, there must be at least one RETURN statement within the function body to return a value to the caller. RETURNS and RETURN do not appear in procedure definitions.
To invoke a stored procedure, use the CALL statement. To invoke a stored function, refer to it in an expression. The function returns a value during expression evaluation.
A procedure is invoked using a CALL statement, and can only pass back values using output variables. A function can be called from inside a statement just like any other function (that is, by invoking the function's name), and can return a scalar value.
Specifying a parameter as IN, OUT, or INOUT is valid only for a PROCEDURE. For a FUNCTION, parameters are always regarded as IN parameters.
If no keyword is given before a parameter name, it is an IN parameter by default.
Parameters for stored functions are not preceded by IN, OUT, or INOUT. All function parameters are treated as IN parameters.
To define a stored procedure or function, use CREATE PROCEDURE or CREATE FUNCTION respectively:
CREATE PROCEDURE proc_name ([parameters])
[characteristics]
routine_body
CREATE FUNCTION func_name ([parameters])
RETURNS data_type // diffrent
[characteristics]
routine_body
A MySQL extension for stored procedure (not functions) is that a procedure can generate a result set, or even multiple result sets, which the caller processes the same way as the result of a SELECT statement. However, the contents of such result sets cannot be used directly in expression.
Stored routines (referring to both stored procedures and stored functions) are associated with a particular database, just like tables or views. When you drop a database, any stored routines in the database are also dropped.
Stored procedures and functions do not share the same namespace. It is possible to have a procedure and a function with the same name in a database.
In Stored procedures dynamic SQL can be used but not in functions or triggers.
SQL prepared statements (PREPARE, EXECUTE, DEALLOCATE PREPARE) can be used in stored procedures, but not stored functions or triggers. Thus, stored functions and triggers cannot use Dynamic SQL (where you construct statements as strings and then execute them). (Dynamic SQL in MySQL stored routines)
Some more interesting differences between FUNCTION and STORED PROCEDURE:
(This point is copied from a blogpost.)
Stored procedure is precompiled execution plan where as functions are not. Function Parsed and compiled at runtime. Stored procedures, Stored as a pseudo-code in database i.e. compiled form.
(I'm not sure for this point.)
Stored procedure has the security and reduces the network
traffic and also we can call stored procedure in any no. of
applications at a time. reference
Functions are normally used for computations where as
procedures are normally used for executing business logic.
Functions Cannot affect the state of database
(Statements that do explicit or implicit commit or rollback are disallowed in function)
Whereas
Stored procedures Can affect the state of database using commit etc.
refrence: J.1. Restrictions on Stored Routines and Triggers
Functions can't use FLUSH statements whereas Stored procedures can do.
Stored functions cannot be recursive Whereas Stored procedures can be.
Note: Recursive stored procedures are disabled by default, but can be enabled on the server by setting the max_sp_recursion_depth server system variable to a nonzero value. See Section 5.2.3, “System Variables”, for more information.
Within a stored function or trigger, it is not permitted to modify a table that is already being used
(for reading or writing) by the statement that invoked the function or trigger.
Good Example: How to Update same table on deletion in MYSQL?
Note: that although some restrictions normally apply to stored functions and triggers but not to stored procedures, those restrictions do apply to stored procedures if they are invoked from within a stored function or trigger. For example, although you can use FLUSH in a stored procedure, such a stored procedure cannot be called from a stored function or trigger.
You can't mix in stored procedures with ordinary SQL, whilst with stored function you can.
e.g. SELECT get_foo(myColumn) FROM mytable is not valid if get_foo() is a procedure, but you can do that if get_foo() is a function. The price is that functions have more limitations than a procedure.
One significant difference is that you can include a function in your SQL queries, but stored procedures can only be invoked with the CALL statement:
UDF Example:
CREATE FUNCTION hello (s CHAR(20))
RETURNS CHAR(50) DETERMINISTIC
RETURN CONCAT('Hello, ',s,'!');
Query OK, 0 rows affected (0.00 sec)
CREATE TABLE names (id int, name varchar(20));
INSERT INTO names VALUES (1, 'Bob');
INSERT INTO names VALUES (2, 'John');
INSERT INTO names VALUES (3, 'Paul');
SELECT hello(name) FROM names;
+--------------+
| hello(name) |
+--------------+
| Hello, Bob! |
| Hello, John! |
| Hello, Paul! |
+--------------+
3 rows in set (0.00 sec)
Sproc Example:
delimiter //
CREATE PROCEDURE simpleproc (IN s CHAR(100))
BEGIN
SELECT CONCAT('Hello, ', s, '!');
END//
Query OK, 0 rows affected (0.00 sec)
delimiter ;
CALL simpleproc('World');
+---------------------------+
| CONCAT('Hello, ', s, '!') |
+---------------------------+
| Hello, World! |
+---------------------------+
1 row in set (0.00 sec)
A stored function can be used within a query. You could then apply it to every row, or within a WHERE clause.
A procedure is executed using the CALL query.
Stored procedure can be called recursively but stored function can not
Beside the answer given above, I would like to add that
Function(s) can be used in combination with other function and expressions and also in a nested fashion (in short they can be used in very complex form form to get the job done what we wants).
Same thing can be implemented in procedure but in procedure we had to done all the work done inside that procedure, meaning in a monolithic fashion code. (Whereas in function(s) can be for every task; a new function can be implemented). So at the end we can get the task done by using a combination of different function.