I would like to debug my stored procedures properly, the easiest way i can think of is to be able to send debug messages to the log file of mysql. is that possible ?!
You can install the User Defined function that is available here...
https://github.com/mysqludf/lib_mysqludf_log
and then use it anywhere in the select query like...
mysql> SELECT log_error(concat(now(), 'error in selecting line 13'));
+--------------------------------------------------------+
| log_error(concat(now(), 'error in selecting line 13')) |
+--------------------------------------------------------+
| 0 |
+--------------------------------------------------------+
1 row in set (0.00 sec)
# tail /var/log/mysqld.log
2010-12-02 03:16:03error in selecting line 13
As I have not heard of anything like that I will recommend you this http://benjisimon.blogspot.com/2007/02/debugging-mysql-stored-procedures.html
or read this topic How do you debug MySQL stored procedures?
Related
Okay, I understand what are errors and warnings in the context of MySQL. But what's the need of note-level warning? I have already searched the MySQL documentation but didn't find anything relevant. It would be better if someone could shed some light on the what are they and why they are useful.
mysql> create database if not exists city;
Query OK, 1 row affected, 1 warning (0.00 sec)
mysql> show warnings
-> ;
+-------+------+------------------------------------------------+
| Level | Code | Message |
+-------+------+------------------------------------------------+
| Note | 1007 | Can't create database 'city'; database exists |
+-------+------+------------------------------------------------+
1 row in set (0.00 sec)
I've always considered Note to be like an "FYI": something happened, or didn't, that may be of interest. The closest definition I can find in the docs is:
... events that do not affect the integrity of the reload operation
which is from the sql_notes server variable, one perhaps not often used outside of mysqldump.
Trawling through the MySQL source code, looks like Sql_Condition::SL_NOTE annotates warnings of this level. There are a few, but they are mostly as you'd expect for non-impactful information:
Event already exists
Table already exists
Query '%s' rewritten to '%s' by a query rewrite plugin
Password set
Sadly, I would have expected the code docblock to give a little more information about them, but it doesn't:
class Sql_condition {
public:
/**
Enumeration value describing the severity of the condition.
*/
enum enum_severity_level { SL_NOTE, SL_WARNING, SL_ERROR, SEVERITY_END };
This might warrant a documentation bug report to MySQL team.
Interestingly, MariaDB has this to say:
A note is different to a warning in that it only appears if the sql_notes variable is set to 1 (the default), and is not converted to an error if strict mode is enabled.
My takeaway from that, in Maria and possibly by extension MySQL: notes are warnings, but ones that can be ignored because no data-loss or side-effect is described.
We're running MySQL 5.5.47 on a number of Debian servers. On some of them, we're seeing the following strange behavior:
mysql> set #TKEY:='ARDARD:fae590c4.ffa2.11e5.a318.0cc47a39aeb4-1460351116';
mysql> select replace(substring_index(substring_index(#TKEY,':',-1),'-',1), '.','-') as guid;
+--------------------------------------+
| guid |
+--------------------------------------+
| fae5a2.1--0cc47a 9ae47a 9aeb4a 9aeb4 |
+--------------------------------------+
This is supposed to extract the middle part of #TKEY (between the : and -) and replace all the periods with hyphens. Where are the spaces coming from? Other parts of the result seem to be jumbled up: 9aeb4 has been duplicated, a2.1 has been shifted left.
This doesn't happen if I assign the substring_index to an intermediate variable.
mysql> set #temp = substring_index(substring_index(#TKEY,':',-1),'-',1);
mysql> select replace(#temp, '.', '-') as guid;
+--------------------------------------+
| guid |
+--------------------------------------+
| fae590c4-ffa2-11e5-a318-0cc47a39aeb4 |
+--------------------------------------+
This only happens on our production servers. I can't reproduce it on our development server or sqlfiddle. I compared all the server variables, and there are no differences that look like they should affect the behavior of string functions (there were initially some differences in character set and collation variables, but I changed the dev server to match the production server and still couldn't replicate the error.
On another production server running MySQL 5.5.41 I get a slightly different wrong result:
mysql> select replace(substring_index(substring_index(#TKEY,':',-1),'-',1), '.','-') as guid;
+--------------------------------------+
| guid |
+--------------------------------------+
| fae590c4-ffa2-11e5-a318-0cc47a 9aeb4 |
+--------------------------------------+
This is correct except that there's a space in place of of the last 3.
Can anyone explain this? Is it just a MySQL bug? I couldn't find anything at bugs.mysql.com.
This appears to be a bug that was fixed in MySQL 5.6.5. There's a somewhat similar bug report regarding LOWER(SUBSTRING_INDEX(...)). It was closed with the comment:
Noted in 5.6.5 changelog.
The result of SUBSTRING_INDEX() could be missing characters when used
as an argument to conversion functions such as LOWER().
I suspect the underlying cause is pointer misuse resulting in buffer overflow and undefined behavior. Hopefully I haven't corrupted any long-lived memory in the server.
I'm using Mysql's command-line client in Screen/Tmux, from Bash in OSX's Terminal.app.
When using arrow-up to re-display a previously run query that spanned more than on line, AND when the cursor is on the very last line of the Terminal, the command in mysql's command history gets 'truncated', or cut off. This never happens when I use the same tools on my Ubuntu workstation
Here's a visual representation of what happens:
Typing some query; nothing wrong here.
+-------------------------------------------+
|mysql> |
|mysql> |
|mysql> |
|mysql>select * from tables where legs = 4 a|
|nd colour = 'green'; |
+-------------------------------------------+
Run it, results are displayed:
+-------------------------------------------+
|| 2 | ....... | ..... | |
|+---+---------+-------+ |
| x rows in set (0.00 sec) |
| |
|mysql> |
+-------------------------------------------+
Hitting [arrow-up] to re-display last query leaves me with:
+-------------------------------------------+
|| 2 | ....... | ..... | |
|+---+---------+-------+ |
| x rows in set (0.00 sec) |
| |
|nd colour = 'green'; |
+-------------------------------------------+
Hit [arrow-up] again, I get:
+-------------------------------------------+
|| 2 | ....... | ..... | |
|+---+---------+-------+ |
| x rows in set (0.00 sec) |
|mysql>select * from tables where legs = 4 a|
|nd colour = 'green'; |
+-------------------------------------------+
Could the be solved by changing a setting? Or is it a bug in Mysql's client?
Software versions:
OSX 10.7.3
Terminal Version 2.2.2 (303)
GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin11)
mysql Ver 14.14 Distrib 5.5.19, for osx10.7 (i386) using readline 5.1
Screen version 4.00.03 (FAU) 23-Oct-06
tmux 1.6
You have a few options I can think of to make your life easier in this regard:
readline commands combined with mysql options:
readline accepts commands similar to basic emacs commands (can be set to vi as well), or example CTRL-a returns you to the start of a line.
this combined with set horizontal-scroll-mode On, a readline that you set in ~/.inputrc, which allows you to get your input in 1 straight line, putting your cursor at the very end. Combine it with CTRL-a to immediately jump to the beginning and it's quite convenient.
~/.inputrc:
$if Mysql
set horizontal-scroll-mode On`
# uncomment the commands below to use vi keybindings
#set keymap vi
#set editing-mode vi
$endif
(some systems, OSX 10.5 for certain I believe use libedit instead of readline, in which case you need to put it all in ~/.editrc, if you're not sure about your system issue the mysql --version command )
To look for commands you issued you also have CTRL-r, which allows you to type in a term and your history will be searched for the last occurence.
interesting commands are:
CTRL-P go to the Previous command in your history
CTRL-N go to the Next command in your history
CTRL-R Reverse-search through your history
CTRL-S Search forward through your history
CTRL-A Move the cursor to the beginning of the line
CTRL-E Move the cursor to the end of the line
CTRL-W delete a Word backwards
ALT-D delete a word forwards
CTRL-F move the cursor Forward 1 character
CTRL-B move the cursor Backward 1 character
ALT-F move the cursor Forward 1 word
ALT-B move the cursor Backward 1 word
ALT-_ undo
Depending on your shell and the underlying they might not all work or be intercepted though. For example on Konsole, which I use on kde, I had to disable flow-control in advanced settings to allow for CTRL-s amongst others.
Finally mysql also gives you the \e command which allows you to edit your commands in your general file editor, if vi or emacs isn't your thing, try nano, it's easy and works well. The main disadvantage of using this is that when scrolling up newlines are ignored bu tabs and spaces aren't. It's a unix only thing but OS X should do fine there, can't check since I don't own any Apple computers, sorry. :)
To more easily use this command you could put a readline string macro in ~/.inputrc
e.g. Control-o: "\\e;\n" would bind CONTROL-o to \e; followed by enter for instant execution. (look at the Keybindings Section)
use an alternate shell:
such as altSQL: it gives syntax colouring, nice history scrolling and some other niceties, big bonus is that you have the source so you can adapt what you want.
drop the shell and go GUI:
Finally I'd like to plug the nice MySQL workbench to work on your databases, it's cross-platform, free and in my humble opinion a nice tool to work with.
I realise it's not a perfect solution and each have advantages and drawbacks but I hope this has helped you along somewhat.
We recently switched to an RDS instance and noticed that bunch of our database tasks were getting triggered 4 hours earlier than needed. On investigating further, the problem is caused by the default time-zone setting (UTC) on the RDS instance. Since this setting can not be altered, we would like to fix the issue on the code level globally across all our applications using this database instance. I tried to set the time-zone on the db instance I create to 'US/Eastern' by using
set GLOBAL time_zone = 'US/Eastern'" OR
set time_zone = 'US/Eastern'"
But that generates an error "Database error: Unknown or incorrect time zone: 'US/Eastern'"
What do you think I am doing wrong here? Does anyone has used any other solutions ?
Unfortunately it's not possible to set the default_timezone in the RDS DB ParameterGroups so your attempt was the right direction already.
$ rds-describe-db-parameters default | grep "time_zone"
DBPARAMETER default_time_zone engine-default string static false
To set the global value via SET GLOBAL you need to have the SUPER privilege which is not granted to you as a RDS user.
The only way to set the time_zone is on a per-connection basis
mysql> SET time_zone = timezone;
On my machines I've tried US/Eastern successfully but I got a quite old generation running.
To determine the timezones you have available log into your box
mysql -h yourboxhost.rds.amazonaws.com -u <youruser> -p
and type
mysql> SELECT * FROM mysql.time_zone_name;
You should get a list of installed and valid timezone names you can set on your instance
+----------------------------------------+--------------+
| Name | Time_zone_id |
+----------------------------------------+--------------+
| Africa/Abidjan | 1 |
| Africa/Accra | 2 |
| Africa/Addis_Ababa | 3 |
| Africa/Algiers | 4 |
| Africa/Asmara | 5 |
| Africa/Asmera | 6 |
| Africa/Bamako | 7 |
| Africa/Bangui | 8 |
| Africa/Banjul | 9 |
| Africa/Bissau | 10 |
| Africa/Blantyre | 11 |
| Africa/Brazzaville | 12 |
| Africa/Bujumbura | 13 |
| Africa/Cairo | 14 |
etc...
You have to set the time_zone each time you connect to your database server
For example if you use the php Mysqli extension you can do this
$mysqli = mysqli_init();
mysqli_options($mysqli,MYSQLI_INIT_COMMAND,"SET time_zone = 'Africa/Brazzaville'" );
mysqli_real_connect($mysqli,$host, $user, $pass,$dbName) or die ('Unable to connect');
Otherwise just manually ( in terms of let your database connector do it ) execute the SET time_zone = '<YOUR_DESIRED_TIMEZONE>' Query right after you've connected to your database
The time_zone setting of RDS database instances can now be modified: https://aws.amazon.com/de/premiumsupport/knowledge-center/rds-change-time-zone/
I did the following steps, So that I could change the timezone
login to RDS and Create New Parameter Group.
Edit the newly created Parameter Group
Set timezone Ex:Asia/Calcutta and Save Changes
Modify RDS instance, change DB's Parameter Group to newly created parameter group
Save And Reboot RDS instance
tldr;
Create a "shared" schema that all your users have EXECUTE access to, create a SPROC that modifies the session timezone and modify the init_connect MySQL parameter to call it.
As Ryan Weir pointed out in his excellent answer in a duplicate question this should probably be avoided if possible. If, however, you are like me and want to implement it for the sake of convenience and sanity then I took Ryan's solution and made a few modifications.
If you have multiple users setup in MySQL with varying permissions then simply putting the sproc in the mysql schema might have problems. To solve this I created a new schema called "shared" and gave all my users EXECUTE access to this schema. I then created the following stored procedure.
DROP PROCEDURE IF EXISTS shared.store_time_zone;
CREATE PROCEDURE shared.`store_time_zone`()
IF NOT (POSITION('rdsadmin#' IN CURRENT_USER()) = 1) THEN
SET SESSION time_zone = 'US/Pacific';
END IF;
I prefer to set 'US/Pacific' to handle daylight savings but you should test this to make sure your MySQL instance recognizes it first. Just execute the following query SET SESSION time_zone = 'US/Pacific'; to make sure it works. To look up your timezone execute SELECT * FROM mysql.time_zone_name;
At this point I recommend testing the permissions before you go modifying the paramter group and potential break everything. Simply connect to the DB (preferably with a user that has low level permissions and/or is commonly used) and execute the following queries.
CALL shared.store_time_zone;
select now();
Hopefully you didn't get any errors and the correct time showed up.
Next you will need to modify the init_connect parameter in the DB Parameter Group that your RDS instance is using. You can do this in the RDS web console, through the API or the command line utility. If you use the command line it will look like this:
$ rds-modify-db-parameter-group PARAMGROUP --parameters "name=init_connect, value='CALL shared.store_time_zone', method=immediate"
If you do it through the web console then you just need to change the value of init_connect.
CALL shared.store_time_zone
Go back to your RDS instance in the web console and scroll the details pane down to the DB Parameter Group. It should say something like (applying) or (in-sync). Once it is (in-sync) go test everything out to make sure there are no problems.
If at this point you run into problems and need to roll things back then I recommend setting the init_connect value to something harmless like:
SET SESSION time_zone = '-00:00';
Setting it back to blank is impossible to do from the web console. See this thread for more details on why one can't restore the empty value for the DB parameter
#Thomas Paine's solution works for me except I had to user user() instead of current_user() as inside the context of init_connect current_user() returns the master RDS user. (By master I do not mean rdsadmin which is the real root user but the user created with the DB instance with most privileges.)
I've built an important MySQL database, with a lot of view, triggers, functions and procedures.
It's very hard to test, and to not forget anything, so, I've written Cucumber scenarios for all of the features of my DB (Insert, Select, etc., request on functions an procedures etc., and views)
This help us a lot when we test the behavior of all this, and even before writing view and other code, it's very helpful to determinate want we really want to do.
My problem is: after writing Cucumber features, we all test by hand in a MySQL Shell.
I'm new in BDD/TDD and Agile methods, but I've done some search to know how to make some automation, but found nothing very interesting for my case.
Is there somebody who can provide some interesting way to create automation for this?
I don't know Ruby, but by example, is it possible to use RSPec directly with MySQL (with some examples)?
Or in another language, or any solution you can think of!
Thanks in advance!
[EDIT]
If found some interesting things with RSpec and MySQL:
Mysql Support For Cucumber Nagios
mysql_steps.rb
My problem is: I don't have any knoledge with Ruby, RSPec, etc.
I'm working on it with the excellent "Pick Axe" book, and RSPec book from PragProg
But I will be very grateful for a little example of of RSpec steps given the code below:
The MySQL Procedure
DELIMITER $$
CREATE PROCEDURE `prc_liste_motif` (
IN texte TEXT,
IN motif VARCHAR(255),
OUT nb_motif INT(9),
OUT positions TEXT)
BEGIN
DECLARE ER_SYNTAXE CONDITION FOR SQLSTATE '45000';
DECLARE sousChaine TEXT;
DECLARE positionActuelle INT(9) DEFAULT 1;
DECLARE i INT(9) DEFAULT 1;
IF
LENGTH(motif) > LENGTH(texte)
THEN
SIGNAL ER_SYNTAXE
SET MESSAGE_TEXT =
'Bad Request: Le motif est plus long que le texte.',
MYSQL_ERRNO = 400;
END IF;
SET positions = '';
SET nb_motif = 0;
REPEAT
SET sousChaine = SUBSTRING_INDEX(texte, motif, i);
SET positionActuelle = LENGTH(sousChaine) + 1;
IF
positionActuelle < LENGTH(texte) + 1
THEN
IF
LENGTH(positions) > 0
THEN
SET positions = CONCAT(positions, ',');
END IF;
SET positions = CONCAT(positions, positionActuelle);
SET nb_motif = nb_motif + 1;
END IF;
SET i = i + 1;
UNTIL LENGTH(sousChaine) >= LENGTH(texte)
END REPEAT;
END$$
The Cucumber feature:
Feature: Procedure prc_liste_motif
In order to precess a string according to a given unit
I want to know the number of units present in the chain and their positions
Knowing that the index starts at 1
Background: the database mydatabase in our SGBDR server
Given I have a MySQL server on 192.168.0.200
And I use the username root
And I use the password xfe356
And I use the database mydatabase
Scenario Outline: Using the procedure with good values in parameters
Given I have a procedure prc_liste_motif
And I have entered <texte> for the first parameter
And I have entered <motif> for the second parameter
And I have entered <nb_motif> for the third parameter
And I have entered <positions> for the fourth parameter
When I call prc_liste_motif
Then I should have <out_nb_motif> instead of <nb_motif>
Then I should have <out_positions> instead of <positions>
Exemples:
| texte | motif | nb_motif | positions | out_nb_motif | out_positions |
| Le beau chien | e | | | 3 | 2,5,12 |
| Allo | ll | | | 1 | 2 |
| Allo | w | | | 0 | |
An exemple of passed test by hand in MySQL:
$ mysql -h 192.168.0.200 -u root -p xfe356
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.5.9 MySQL Community Server (GPL)
Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> USE mydatabase
Database changed
mysql> SET #texte = 'Le beau chien';
Query OK, 0 rows affected (0.00 sec)
mysql> SET #motif = 'e';
Query OK, 0 rows affected (0.00 sec)
mysql> SET #nb_motif = NULL;
Query OK, 0 rows affected (0.00 sec)
mysql> SET #positions = NULL;
Query OK, 0 rows affected (0.00 sec)
mysql> SET #out_nb_motif = 3;
Query OK, 0 rows affected (0.00 sec)
mysql> SET #out_positions = '2,5,12';
Query OK, 0 rows affected (0.00 sec)
mysql> CALL prc_liste_motif(#texte, #motif, #nb_motif, #positions);
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT #nb_motif = #out_nb_motif AND #positions = #out_positions;
+-----------------------------------------------------------+
| #nb_motif = #out_nb_motif AND #positions = #out_positions |
+-----------------------------------------------------------+
| 1 |
+-----------------------------------------------------------+
1 row in set (0.00 sec)
thanks in advance for your help !
Here is some pseudocode for one way you could test your database with RSpec:
describe "prc_liste_motif" do
before(:all) do
# Set up database connection here
end
describe "good values" do
context "Le beau chien" do
let(:texte) { "Le beau chien" }
# Set up other variables here
let(:results) { # call prc_liste_motif here }
it "has the correct out_nb_motif" do
out_nb_motif = # however you derive this from the results of the procedure
out_nb_motif.should == 3
end
it "has the correct out_positions" do
# test out_positions here
end
end
end
end
One thing I noticed in your sample manual test was how you are checking the results:
SELECT #nb_motif = #out_nb_motif AND #positions = #out_positions;
This will tell you whether or not those two values are correct, but if you get 0 results for this query, you do not immediately know which of the two values is incorrect and you do not know what the value you are getting instead is; getting that information requires more investigation.
By splitting up the checking for these two values into 2 RSpec tests, when the tests have finished running you can know if both are correct, if one is incorrect, or if both are incorrect. If one or both are incorrect, RSpec will also return a message for the failed test that says "Expected 3, got 4" which can help you debug faster.
As you add more tests for different inputs, I recommend refactoring the pseudocode I've given here to use shared_examples_for. The PragProg RSpec book that you're already reading is a great reference.
Cucumber's a natural-language BDD tool, which is designed to get non-technical stakeholders on board so that you can have conversations with them about what the system should do. It also lets you reuse steps quite easily - similar contexts, events and outcomes.
If you're writing a database, I think it's likely that your users, and the audience for that database, will be technical. There may also be limited opportunities for reusing steps, so Cucumber may not be the best tool. You're probably right about moving to something like RSpec instead. The English-language tools introduce a layer of abstraction and another aspect to maintenance which can be a pain in the neck, so I'd pick a tool which suits what you're doing, rather than starting with the tool and trying to fit your needs around it.
Once you've done that, you can either use ActiveRecord to create domain-object results from your queries, or you can just call the SQL directly. RSpec is just Ruby with some matchers. This forum might help you.
Something else you could do is to knock up a small application which actually uses your database. Not only will this ensure that your database is genuinely valuable; it will provide users with examples of how to use it. That won't be very difficult to do with Rails. If you go down this route, then you can use Cucumber with something like Webrat or Watir if you want to, because you'll be documenting the kind of things that other applications could use your database for at a higher level. Just make sure that
any live examples you provide go to
test data instead of production, and
that
if your little example app
suddenly turns into the real app
(which sometimes happens), you're in a position to spot that happening and take appropriate political and financial steps.
Java also has quite a lot of support for MySQL and you could use Hibernate instead of ActiveRecord, but I think the maintenance costs will be much less in Ruby.