MySQL 5.0 Reference Manual :: 10 Data Types :: 10.4 String Types :: 10.4.3 The BLOB and TEXT Types

Previous / Next / Up / Table of Contents

User Comments

Posted by Volnei Puttini on June 22 2007 12:04pm

[Delete] [Edit]

A pratical example of how write and read images into MySQL tables,
using Trolltech Qt4/C++

This example is for who reads/record images in tables
using fields BLOB.

First: Create a table, for example:
CREATE TABLE picture (
ID INTEGER AUTO_INCREMENT,
IMAGE BLOB,
PRIMARY KEY (ID)
) ENGINE=InnoDB;


2) To read a image to a QByteArray

QString fileName = "IMAGE.JPG";

QImage image(filaName);
LBL_IMAGE->setPixmap(QPixmap::fromImage(image)); // Put image into QLabel object (optional)

// load image to bytearray
QByteArray ba;
QFile f(fileName);
if(f.open(QIODevice::ReadOnly))
{
ba = f.readAll();
f.close();
}

// Writing the image into table
QSqlDatabase::database().transaction();
QSqlQuery query;
query.prepare( "INSERT INTO picture ( IMAGE ) VALUES (:IMAGE)" );
query.bindValue(":IMAGE", ba);
query.exec();
if( query.lastError().isValid()) {
qDebug() << query.lastError().text();
QSqlDatabase::database().rollback();
} else
QSqlDatabase::database().commit();

3) Now, recovery the field with the image

int idx = 1; // The records ID to recover

QSqlDatabase::database().transaction();
QSqlQuery query;
query.prepare("SELECT ID, IMAGE FROM picture WHERE ID=:ID");
query.bindValue(":ID", idx);
query.exec();
query.next();
if( query.lastError().isValid()) {
qDebug() << query.lastError().text();
QSqlDatabase::database().rollback();
} else {
QByteArray ba1 = query.value(1).toByteArray();
QPixmap pic;
pic.loadFromData( ba1);

// Show the image into a QLabel object
LBL_IMAGE->setPixmap(pic);
QSqlDatabase::database().commit();
}

This example works fine and I use it frequently.

Thanks.

Posted by Bryce Nesbitt on April 4 2008 4:36pm

[Delete] [Edit]

On MS Windows the "no DEFAULT" rule is an error, while on other platforms it is often a warning. While not a bug, it's possible to get trapped by this if you write code on a lenient platform, and later run it on a strict platform:

mysql> show warnings;

+---------+------+------------------------------------------------------+
| Level   | Code | Message                                              |
+---------+------+------------------------------------------------------+
| Warning | 1101 | BLOB/TEXT column 'abcdef' can't have a default value |
+---------+------+------------------------------------------------------+

Posted by [name withheld] on April 27 2008 11:17am

[Delete] [Edit]

I struggled for some time to utilize mysql's blob column to store images and especially large files with good performance in and out. I found this tutorials implementation very useful: http://www.dreamwerx.net/phpforum/?id=1

Posted by Rajiv Kapoor on December 9 2008 9:46am

[Delete] [Edit]

Following way we can store blob data in a table using MYSQL:
INSERT INTO PICTABLE (MYID, PIC) VALUES (3, LOAD_FILE('/PHP/ME.JPG'));

Posted by Kristian Köhntopp on October 2 2009 3:19pm

[Delete] [Edit]

Simon Mudd is right, but there are several things that must come together to make this bad:

1. You must have a query that has an EXPLAIN which includes 'using temporary'. If 'using temporary' is shown in your EXPLAIN plan, then a temporary table is being created either in MEMORY or as MyISAM table on disk. MySQL prefers MEMORY, but there are situations where it is forced to go to disk.

2. You must have a query which includes any TEXT or BLOB type in the column list, that is in the part of the query between SELECT and FROM. The actual size of the column or its content do not matter - even a TINYTEXT that is empty is enough.

Since the MEMORY storage engine cannot represent any TEXT or BLOB types at all, this forces MySQL to realize the table as an on-disk MyISAM table.

How to diagnose:

1. Run show session status:

kris@localhost [test_world]> show session status like 'Created_tmp%tables';

+-------------------------+-------+
| Variable_name           | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 3     |
| Created_tmp_tables      | 7     |
+-------------------------+-------+

2 rows in set (0.00 sec)

2. Execute the query. Make sure it is not cached:

kris@localhost [test_world]> select sql_no_cache * from kris group by countrycode order by population;
...
232 rows in set (0.00 sec)

3. Check show status again:

kris@localhost [test_world]> show session status like 'Created_tmp%tables';

+-------------------------+-------+
| Variable_name           | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 4     |
| Created_tmp_tables      | 8     |
+-------------------------+-------+

2 rows in set (0.00 sec)

As you can see the Created_tmp_tables counter increased by one (in MySQL 5.0 is increases by two because the SHOW STATUS itself creates an in-memory tmp table which is being counted). If the table goes to disk as MyISAM instead of being a MEMORY Table, Created_tmp_disk_tables is also incremented by one, as seen here. This is slow.

The test table I used is using the MySQL world database and

mysql> create table kris as select * from City;
mysql> alter table kris modify column name text;
mysql> alter table kris add primary key (id);

The test query shown above is 'using temporary' because I group by one column and order by another, forcing MySQL to use a temporary table.

Had I been using the same query on the original City table from the world database, a tmp table would have been needed as well, but it would have been created as a MEMORY table as the original name column is a CHAR(35). So Created_tmp_tables is being bumped by one, but Created_tmp_disk_tables is not.

Had I been leaving off the SQL_NO_CACHE, the query cache would have been catching repeated executions of the same query in testing and the counters would not have been moving at all except for the very first test.

Add your own comment.

Top / Previous / Next / Up / Table of Contents