» tagged pages
» logout

sorted by: recent | see : popular
Content Tagged with Engine + MySQL

A cool idea - Revision engine


Yesterday I saw an announcement in the MySQL internals@ list, about a new storage engine being released. DDengine has created a revision engine, a sort of embedded proxy inside MySQL that keeps track of the changes you do to your data.
The idea is clever. You write to your table, update and delete without any concern, and the revision engine stores your changes in the background.
I wanted to tried the engine on my laptop (Mac OSX), but there was no binary available for this architecture. I contacted the authors and I received prompt assistance until I had the product installed. Unfortunately, it crashes immediately. Well, it's to be expected for a version 0.1.
I then tried on Linux, and also here I received very quick assistance from Peter Benjamin Volk, Project Head at DDengine.
It now works on Linux, although it's very basic at the moment.
The documentation says that there are two ways of using the revision engine. One with embedded changes, which involves a silent alteration of your table structure to include the revision info, and one with two tables, one of which is created behind the scenes.
For example:
create table t1 (
id int not null primary key,
c char(10)
) engine=revision comment="InnoDB:DOUBLE";
show tables;
+----------------+
| Tables_in_test |
+----------------+
| t1 |
| t1_revision |
+----------------+

desc t1;
+-------+----------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------+----------+------+-----+---------+-------+
| id | int(11) | NO | PRI | NULL | |
| c | char(10) | YES | | NULL | |
+-------+----------+------+-----+---------+-------+

desc t1_revision;
+--------------------+---------------------+------+-----+
| Field | Type | Null | Key |
+--------------------+---------------------+------+-----+
| id | int(11) | NO | PRI |
| c | char(10) | YES | |
| revision_id | int(10) unsigned | NO | PRI |
| revision_timestamp | timestamp | NO | |
| revision_deleted | tinyint(3) unsigned | NO | |
+--------------------+---------------------+------+-----+
The "InnoDB:DOUBLE" tells the engine to use a second table for revision info.
Operations on the table are transparent.
insert into t1 (id,c) values (1, 'aaa'), (2, 'bbb');
Query OK, 2 rows affected (0.01 sec)
Records: 2 Duplicates: 0 Warnings: 0

insert into t1 (id, c) values (3, 'ccc'), (4, 'ddd');
Query OK, 2 rows affected (0.01 sec)
Records: 2 Duplicates: 0 Warnings: 0

select * from t1;
+----+------+
| id | c |
+----+------+
| 1 | aaa |
| 2 | bbb |
| 3 | ccc |
| 4 | ddd |
+----+------+
4 rows in set (0.00 sec)

select * from t1_revision;
Empty set (0.00 sec)
So far, nothing unusual. Let's try some changes.
update t1 set c ='changed' where id = 3;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

select * from t1;
+----+---------+
| id | c |
+----+---------+
| 1 | aaa |
| 2 | bbb |
| 3 | changed |
| 4 | ddd |
+----+---------+
4 rows in set (0.00 sec)

show variables like '%revision%';
+----------------------+---------+
| Variable_name | Value |
+----------------------+---------+
| revision_select_mode | current |
+----------------------+---------+
1 row in set (0.00 sec)

select * from t1_revision;
+----+------+-------------+---------------------+------------------+
| id | c | revision_id | revision_timestamp | revision_deleted |
+----+------+-------------+---------------------+------------------+
| 3 | ccc | 1 | 2008-09-30 05:45:49 | 0 |
+----+------+-------------+---------------------+------------------+
1 row in set (0.00 sec)

delete from t1 where id = 2;
Query OK, 1 row affected (0.01 sec)

select * from t1_revision;
+----+------+-------------+---------------------+------------------+
| id | c | revision_id | revision_timestamp | revision_deleted |
+----+------+-------------+---------------------+------------------+
| 3 | ccc | 1 | 2008-09-30 05:45:49 | 0 |
+----+------+-------------+---------------------+------------------+
1 row in set (0.00 sec)

set revision_select_mode = 'deleted';
Query OK, 0 rows affected (0.01 sec)

select * from t1_revision;
+----+------+-------------+---------------------+------------------+
| id | c | revision_id | revision_timestamp | revision_deleted |
+----+------+-------------+---------------------+------------------+
| 2 | bbb | 1 | 2008-09-30 05:47:14 | 1 |
+----+------+-------------+---------------------+------------------+
1 row in set (0.00 sec)

select * from t1;
+----+---------+
| id | c |
+----+---------+
| 1 | aaa |
| 3 | changed |
| 4 | ddd |
+----+---------+
3 rows in set (0.00 sec)
The session variable revision_select_mode changes the revision data that to be shown.
At the moment, there is no revert mechanism (or if there is, it's undocumented), but the idea is cool, and I think that this engine will become very useful.

MySQL: Planet MySQL

Monty speaks about Maria

Michael Widenius, commonly referred to as Monty, gave a very interesting talk on Maria at OSCON 2008. He not only had a talk in the main session, that was well attended, titled Architecture of Maria, the New Transactional Storage Engine for MySQL (slides are available in ODP there), he also gave one at the Sun booth, where we were running our own little “unconference”.

For those reading this in a feed reader, there’s a 23 minute video of Monty telling us more about Maria, a bit about its motivations, architecture, and where the team is at now. If you’re interested in grabbing the code, check out the MySQL + Maria Storage Engine branch on Launchpad.

MySQL: Planet MySQL

Using Federated Servers in MySQL? 5.1

[HoneyMonitor is a MySQL? GUI Tool for Windows? Systems. Server Administration, Database and Database Objects Administration, Code Development, Server Monitoring, Performance Monitoring, Performance Auditing. Read more on http://www.honeysoftware.com]

This is a short tutorial on the features implemented in HoneyMonitor for the use and administration of Federated Servers . It could be useful for Users who are new to the product and want to get start with it or to whom want to learn the basis of Federated Servers in MySQL? 5.1

More details on the HoneyMonitor Reference Manual at http://www.honeysoftware.com/honeymonitor/doc.

 

Contents

  • Introduction
  • Federated Server Metadata
  • Retrieving the list of Federated Servers
  • The Federated Server Editor
  • Creating a Federated Table Using the Create Table Wizard
  • Other Resources
  • About the Author

1. Introduction

Starting from MySQL? v.5.1.15-beta you can use the CREATE / ALTER / DROP SERVER syntax to manage your Federated Servers. 

This can help you creating a FEDERATED table in a fast and more efficient way. In fact if you first create a Federated Server using the CREATE SERVER syntax, then you can create a federated table using the following simple create table option

CONNECTION = ‘federated_server_name’

instead of the longer

CONNECTION = ‘mysql://user_name [:password]@host_name[:port_num] /db_name/tbl_name’

Note that starting from version 5.1.26-rc, the FEDERATED storage engine is disabled by default in binary distributions. The engine is still available and can be enabled by starting the server with the –federated option.

For more information about Federated Server, please visit http://dev.mysql.com/doc/refman/5.1/en/federated-storage-engine.html.

 

2. Federated Server Metadata

In the database mysql there is a table -  mysql.servers ? where all the information about the Federated Servers are stored:

mysql> DESCRIBE mysql.servers;
+————-+———-+——+—–+———+——-+
| Field       | Type     | Null | Key | Default | Extra |
+————-+———-+——+—–+———+——-+
| Server_name | char(64) | NO   | PRI |         |       |
| Host        | char(64) | NO   |     |         |       |
| Db          | char(64) | NO   |     |         |       |
| Username    | char(64) | NO   |     |         |       |
| Password    | char(64) | NO   |     |         |       |
| Port        | int(4)   | NO   |     | 0       |       |
| Socket      | char(64) | NO   |     |         |       |
| Wrapper     | char(64) | NO   |     |         |       |
| Owner       | char(64) | NO   |     |         |       |
+————-+———-+——+—–+———+——-+
9 rows in set (0.01 sec)

mysql> SELECT * FROM mysql.servers LIMIT 1\G
*************************** 1. row ***************************
Server_name: server1
       Host: localhost
         Db: mysql
   Username: root
   Password:
       Port: 6005
     Socket:
    Wrapper: mysql
      Owner:
1 row in set (0.00 sec)

 

3. Retrieving the list of Federated Servers

Federated Servers are listed in the Federated Servers node of the Server Objects List (Fig. 1).

Server Objects List - Federated Server

Fig.1: Server Objects List - Federated Servers

You can create / edit / drop a Federated Server using node’s popup menu.

 

4. The Federated Server Editor

The Federated Server Editor (Fig. 2), allows you to create / edit a Federated Server.

The Federated Server Editor

Fig. 2: The Federated Server Editor - Advanced Tab

You have to set the server name and (at least) one option to create a Federated Server.

After you set the Server’s parameters you can click on the button ‘Test Connection’ to test the connection to the MySQL? Server.

After the creation of the Server, the SQL Tab (Fig. 3) ? now enabled - will contain the SQL syntax for recreating the current Server.

The Federated Server Editor - SQL Tab

Fig. 3: The Federated Server Editor - SQL Tab

 

5. Creating a Federated Table Using the Create Table Wizard

The Create Table Wizard helps you creating tables in a simply and fast way (Fig. 4).

The Create Table Wizard

Fig. 4: The Create Table Wizard

The Wizard includes a ‘Connection’ option; when creating a Federated Table you can fill it with the connection string (’mysql://user_name[:password]@ host_name [:port_num]/db_name/tbl_name’) or just with the name of the Federated Server you created with Federated Server Editor.

By clicking on button at the right of the ‘Connection’ field, the Federated Server List will be opened thus helping you choosing an existing Federated Server - without the need of writing its name - or creating one more (Fig. 5).

The Federated Server List

Fig. 5: The Federated Server List

 

6. Other Resources

If you want to learn more on HoneyMonitor please visit the Project Home Page, at http://www.honeysoftware.com/honeymonitor, or check out one of the following resources:

7. About the Author

Santo Leto is a two years experience MySQL? DBA and Developer.
Leader and main programmer of the HoneyMonitor Project, he graduated in physics and he lives in Italy, where he works from home.

 

MySQL: Planet MySQL

Working with Google App Engine

Yesterday I took a more serious look at Google App Engine, I got a developer account some weeks ago.

After going though the getting started demo some time ago, I chose an idea for a FaceBook Application and started in true eXtreme Programming (XP) style (i.e. What’s the bare minimum required for first iteration). I taught myself some Python and within just a few minutes had some working data being randomly generated totally within the development SDK environment On my MacBook. I was not able to deploy initially via the big blue deploy button, the catch is you have to register the application manually online.

Then it all worked, and hey presto I’ve got my application up at provided domain hosting at appspot.com

Having coming from a truly relational environment, most notably MySQL of recent years I found the Datastore API different in a number of ways.

  • There is no means of Sequences/Auto Increment. There is an internal Unique Key, but it’s a String, not an integer, not enabling me to re-use it.
  • The ListProperty enables the use of Lists in Python (like Arrays) to be easily stored.
  • The ReferenceProperty is used as a foreign key relationship, and then can be more reference within an object hierarchy
  • I really missed an interactive interface. You have no abililty to look at your data, specifically for me I wanted to seek some data, then I wanted to delete some data, but I had to do all this via code.

Having developed a skelaton FaceBook application before in PHP, I figured a Python version would not be that much more work, but here is where I good stumped Information at Hosting a Facebook Application on Google AppEngine leveraging the PyFacebook project didn’t enable me to integrate Google App Engine with FaceBook just yet.

This had me thinking I need to resort to a standalone simply Python Facebook application to confirm the PyFacebook usage. Now my problems started. Under Mac it’s a lot more complex to install and configure Python/Django etc then under Linux. I tried to do it on my dedicated server, but drat Python is at 2.3.4, and it seems 2.5.x is needed.

Still it was a valuable exercise, I dropped the FaceBook goal and just worked on more Google App Engine stuff. Still early days, but it was productive to try out this new technology.

What I need to work on now is how to hold state within Python infrastructure so I can manage a user login and storing and retrieving user data for my sample app.

MySQL: Planet MySQL

Getting Started Using NDB on MySQL University

We haven’t had a MySQL University session in a while (a semi-spring break?), but tomorrow’s session (May 8) should be real interesting. MySQL Cluster developer, Stewart Smith, will host a session titled Getting Started Using NDB. It will happen on May 8, at 13:00 UTC.

One of the most common queries I receive is from people wanting to install or get started with NDB usage (ok, strictly speaking, they want to “cluster” MySQL, and I’m happy Stewart is using the word “NDB” which refers to the storage engine). All in all, it should be a great session, so I encourage you to join in the festivities.

Lucky for me, 13:00 UTC equates to 06:00 PST, while I’m in San Francisco. So I should definitely attempt to be there.

MySQL: Planet MySQL

After the MySQL Conference and Expo...

That week at the conference was a busy week for me - as busy as any developer meeting I have had with MySQL in recent years. I had a great time seeing old faces again and it was much like old times talking, chatting and coding with them. In particular, I spent much of my time with Patrick Galbraith, Eric Herman and Arjen Lentz.
Great progress was made: I worked with Patrick getting my ancient patch integrated into FederatedX so that it can support transactions. I also worked a bit with Arjen getting his OQGraph engine starting to answer a few simple queries. Of course, most importantly, I worked with Eric to finalize the plan for our presentation on "External Language Stored Procedures for MySQL". We also worked on getting the source repository hosted on LaunchPad and created a small team group to manage it. You can check it out here: Team Page
Now, just relaxing and chatting with people... and hopefully I will get a moment to get an updated patch out and to publish the presentation and demonstration notes. What I'd like to get done soon is to sync the External Lang repository with the current mysql-5.1 launchpad repository and maybe a small patch to support two-phase commits with FederatedX.

MySQL: Planet MySQL

Liveblogging: Architecture of Maria By Monty Widenius

Architecture of Maria: A New Storage Engine with a Transactional Design

Goals of Maria:


  • ACID compliant
  • MVCC, transactional
  • default non-transactional and default transactional storage engine for MySQL
  • MyISAM replacement, including temporary table use
  • Storage engine good for data warehousing.
  • Allow any length transactions to take place
  • all indexes should have equal speed (clustered indexes are not in the plan)
  • log shipping — incremental backups just by copying the logs
  • used as a standalone library
  • fast count(*)
  • allow copying of Maria tables between different Maria servers
  • Better blob handling (than MyISAM) — no memory copying, or extra memory used for blobs on INSERT/UPDATE
  • BLOBs are allocated in big sequential blocks means that there is less fragmentation over time.
  • BLOBs are stored so Maria can be easily extended to have access to any part of a BLOB with a single fetch in the future

Maria is actually faster than MyISAM.
Will support READ COMMITTED and REPEATABLE READ (was a specific question).

“You should be able to upgrade Maria and have it just work, without ever having to backup and restore as part of the upgrade.”

Why do we need 2 storage engines, Maria and Falcon?
More storage engines = more scenarios to be able to handle. Falcon good for lots of memory, and shorter queries, Maria is to take care of long transactions and data warehousing side, and also to be an overall “good” engine for most purposes (at least as good as InnoDB).

Project plan — MySQL 5.1 and higher. Maria strives to be bug-free.

Maria 1.0 = “crash safe”, released in Jan 2008. Cacheable row format.
Maria 1.5 = “concurrent insert/select”, Apr/May 2008. Will be merged into the MySQL 6.0 release. Non-transactional.
Supports:


  • External/internal row CHECK/REPAIR/compressing
  • Different row formats — fixed size, dynamic length, compressed, page
  • Fast checksum of a table
  • maria_check

MySQL 6.0 (includes Maria)
Maria 2.0 = “Transactional and ACID” alpha, Q4 2008
Maria 3.0 = “High concurrency + Online backup” alpha, Q1 2009; GA, Q2 2009

Advantages of Maria compared to MyISAM

  • Data, index and statistics are crash safe. On crash, everything will rollback to the state of the start of the statement or last LOCK TABLES commands.
  • Can replay everything from the log. Still need to backup the .frm files though.
  • LOAD INDEX can skip index blocks for unwanted indexes
  • most parts of Maria have unit tests.
  • Supports all MyISAM formats and a new PAGE format, where data is stored in pages — this is:

    • Only crashsafe, transactional row format for Maria
    • Versioned, so you can have concurrent insert/select
    • Cached by page cache so will give noticeable speed improvement on systems with poor data caching

  • MyISAM is non-transactional only, Maria can support transactional (crash-safe) and non-transactional formats
  • Maria uses big log files by default — 1G
  • Log control file = maria_log_control
  • Log files = maria_log.?????
  • If a log file is already in use by a transaction, create a new one, otherwise, reuse it. SHOW LOGS will show which logfiles exist, which ones are in use, and you can PURGE the logs.
  • Maria uses 8K pages by default (MyISAM uses 1K pages by default. This should be faster on static size indexes but slower on variable length keys, until Maria 2.0 where there will be a directory for index pages.

Before Apr/May release of Maria 1.5

  • Statistics and indexes versioned (data is already versioned)
  • FULLTEXT (boolean mode) and R-TREE indexes need to be made crash-safe
  • Parallel recovery

Disadvantages, not likely to be fixed

  • No external locking
  • One page size for both index and data
  • only one page cache
  • index number and checksums require an extra 5 bytes per page
  • doesn’t support RAID
  • Minimum data file size for BLOCK format is 16K, with 8K pages
  • Storage of rows

XDB indexes — group records, and get the min and max for each group (groups are not sorted), and save that in a separate block. This means that stats like min and max are very fast. This is something that will help data warehousing queries.

Resources:

Best quote from Monty: “You don’t steal ideas in open source. You respect people.”

MySQL: Planet MySQL

Notes from Architecture of Maria Storage Engine

Here is the quick notes from the session “Architecture of Maria” from Monty Widenius, one of my all time favorite developer and founder of MySQL.

  • Goals
    • To create ACID complaint and Multi-version concurrency control (MVCC)  transactional storage engine for MySQL
    • To replace existing replacement for MyISAM and if possible the default transactional database
    • Maria can run in both transactional and non-transactional, so its easy to replace existing transactional and non-transactional engines
    • To create a storage engine which is good for data warehousing (DW) purposes
  • Why Falcon and Maria
    • two different architectures
    • different in feature, compatibility, performance
    • Target is for data warehousing
  • Project plan
    • 5.1 + Maria release
      • 1.0 - crash-safe, released in jan, 2008
      • 1.5 - concurrent insert/select, released in apr-may 2008
    • 2008 it will be merged with 6.0
    • 6.0 + Maria
      • 2.0 - transactional and ACID (Q4-2008)
      • 3.0 - high concurrency & online backup (Q1-2009)
      • 3.0 - GA by Q2-2009
    • 6.1 + Maria
      • 4.0 - Data warehousing Q3/2009
  • Technical goals
    • MVCC
    • ACID
    • MyISAM replacement
    • Internal temporary tables replacement
    • All Indexes should have equal speed
    • Allow any length transactions to work
    • Log shipping (incremental backups, just by coping the logs)
    • Can be used as standalone library
    • copying of tables b/w different Maria servers
    • Better blob handling
    • Select count ( * )  and table checksums
    • Efficient storage on disk
    • Small footprint
    • behavior of transactional and non-transactional is dynamic
  • Maria 1.0 is basically a crash-safe, non-transactional version of MyISAM with cacheable row format
  • Primary goal is to make Maria of good quality
  • Comparison to MyISAM
    • Mostly everything is compatible
    • repair, compression of rows
    • different row formats (fixed size, dynamic, compressed + pages)
    • fast count ( * )  and checksum
    • different index compress format
    • after a clean shutdown, one can copy logs and build a new server
  • Advantages
    • Data, index and statistics are crash-safe
    • Can replay everything from log
    • include create/drop/rename/truncate tables
    • backup of Maria by just coping logs
    • Load index can skip index blocks for not wanted indexes
    • It has unit tests that we missed it for MyISAM
    • support both crash-safe, transactional
    • non-txn will use less space
    • supports all MyISAM row formats +PAGE format
  • Differences to MyISAM
    • uses big log files (1G by default)
    • has log control file
    • Uses 8K pages by default (MyISAM 1K)
  • Disadvantages to MyISAM
    • repair with many threads not yet
  • Will not be fixed
    • No external locking
    • Maria has one page size for both index and data
    • Maria has only one page cache
    • Index number + checksums requires 5 extra bytes per page
    • It does not support RAID
    • Min data file size for BLOCK format is 16K
    • Storage for very small rows (< 25bytes) is not optimal
  • TODO
    • Make indexes and statistics versioned
    • Make fulltext (boolean mode) and R-tree index crash safe
    • Parallel-recovery (rolling feature)
  • Well documented from day-1 (architecturefaq, everything), maria@lists.mysql.com
  • XDB indexes for Maria-4.0

MySQL: Planet MySQL

Letters to the Editor (1)

I recently got this email from a reader on my site and since I haven't posted for a while, I thought it might be a good discussion:


Jay,

I've been reading your site and had a question that you might have good insight for.  

I'm working on a high-traffic website that includes forums.  All the code is custom PHP, including the forums, simply because the PHP BB software out there doesn't scale as large and as well as I wanted.  I've implemented heavy memcached usage, distributed databases, etc. to handle any level of growth we may hit.

read more

MySQL: Planet MySQL

Interested in writing a book about the DB2 for i5/OS Storage Engine?

IBM plans a residency to write a Redbook about the IBM DB2 for i5/OS as a Database Engine for MySQL:

Seize this opportunity to be among the first, elite IBM System i professionals worldwide to gain hands-on and practical experience with the MySQL on i5/OS. Working alongside and exchanging knowledge with some of the top database experts in the System i, you will develop a competitive edge that will serve you well in successful service delivery to System i clients. MySQL is used extensively with opensource PHP applications. As our customers deploy PHP web applications, many of them are looking to run MySQL as well.

The residency will take place in Rochester, MN from April 21st to May 16th. This book is going to be a nice followup to the first Redbook titled "Discovering MySQL on IBM i5/OS", which was finished in December last year. If you are curious to learn how to install MySQL on this platform (or would like to prepare yourself for participating in this upcoming residency), you can get a PDF from there, too!

I initially wanted to attend this residency myself, as I have been involved in writing a Redbook before and really enjoyed the experience. However, recent changes forced me to retract my offer to volunteer. IBM covers the travel expenses and will take care of accomodation for the time of the residency. If you are interested and think you have the time and skills and you would like to expand your knowledge about MySQL on the i5/OS Platform, please contact me at firstname at MySQL dot com!

MySQL: Planet MySQL

Project: RSS Feed Storage Using InnoDB

I’ve been coding a couple of scripts that run on 5 minute intervals to grab RSS/Atom feed data from http://mysql-dba.com and import that into a MySQL database. It idea is to create a search function for the site that will look at all past data from the aggregated feeds. Since there are multiple pollers running at different intervals I decided to use Innodb for the read/write nature of the poller/processing scripts.

This is very simple so far - and as such I felt it should be documented from the start unlike many of my other projects. Here’s the feed table that is storing the information from the RSS feeds.


mysql> show create table feed_items\G
*************************** 1. row ***************************
Table: feed_items
Create Table: CREATE TABLE `feed_items` (
`id` bigint(20) NOT NULL auto_increment,
`rss_site_id` int(11) NOT NULL,
`item_title` varchar(255) NOT NULL,
`item_link` varchar(255) NOT NULL,
`item_description` varchar(255) NOT NULL,
`item_guid` varchar(255) NOT NULL,
`item_pubDate` varchar(255) NOT NULL,
`Creation_time` datetime NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `rss_site_id` (`rss_site_id`,`item_link`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

MySQL: Planet MySQL

What Applications Are Good For MySQL Cluster?

Someone asked me what applications were good/bad for MySQL Cluster. As I’ve now actually had experience with a Cluster setup and a real-life application of it, and dug through the manual, I present a few characteristics of applications that will work with Cluster, and why they are so (so that if you have an [...]

MySQL: Planet MySQL

Sphinx - Free open-source SQL full-text search engine

Sphinx is a full-text search engine, distributed under GPL version 2. Commercial licensing (eg. for embedded use) is also available upon request. Generally, it's a standalone search engine, meant to provide fast, size-efficient and relevant full-text sea

opensource: del.icio.us tag/opensource

These past weeks

Ever since I submitted the "External Language Stored Procedures" project which Eric and myself have been working on to be listed on FreshMeat, it has gained a small number of interested users and we have just started to get some feedback. Yay! Always nice to know when people are using your code. Okay, so one of the emails contained a feature request: Support for PHP stored procedures. I think I shall play with that during my Christmas vacation next week. The weekend refresh took a little longer than expected to complete due to changes inside the mysqld code but I managed to test and push the changes before midnight.

Sometimes a task morphs gradually as requirements creep in... WL#3771 is one of those where even the title and direction has changed completely through its evolution.. Last week and this, I have completed a draft of the code in the task's current incarnation and hope it will be deemed acceptable and pushable soon.

A few days ago, I had just completed porting the Falcon storage engine to Sparc and PowerPC (again). Verified that all tests which aren't disabled complete successfully. I have been told that Jim will review the patch and may push portions vaguely based upon my patch sometime in the hand-wavy future.

MySQL: Planet MySQL

Page 1 | Next >>