Showing entries 1 to 10 of 13
3 Older Entries »
Displaying posts with tag: refactoring (reset)
Re-factoring some internals of prepared statements in 5.7

[ this is a re-posting of what I published on the MySQL server team blog a few days ago ]
 
When the MySQL server receives a SELECT query, the query goes through several consecutive phases:

  • parsing: SQL words are recognized, the query is split into different parts following the SQL grammar rules: a list of selected expressions, a list of tables to read, a WHERE condition, …
  • resolution: the output of the parsing stage contains names of columns and names of tables. Resolution is about making sense out of this. For example, in “WHERE foo=3“, “foo” is a column name without a table name; by applying SQL name resolution rules, we discover the table who contains “foo” (it can be complicated if subqueries or …
[Read more]
Poor programming practices

When will it stop. These amateur programmers that simply cut/paste code really affect those good programmers in the ecosystem trying to make a decent living. I was reviewing a developed (but incomplete) PHP/MySQL system using a common framework (which in itself is irrelevant for this post).

In one source file there were 12 repetitions of the following code:

   //permissions
    $this->security_model->setUserPermissions($id);
    if (!array_key_exists($id,$this->session->userdata['permissions']) OR
        !array_key_exists('id', $this->session->userdata['permissions'][$id]) OR
        !array_key_exists('scope', $this->session->userdata['permissions'][$id]['name'])){
      $this->session->set_flashdata('alert', 'You are not authorized to go there.');
      redirect($this->agent->referrer());
    }

It’s bad enough when code is repeated and not put in a simple re factored function. When it’s …

[Read more]
Getting rid of huge ibdata file, no dump required, part II

This post continues Getting rid of huge ibdata file, no dump required, part I, where I describe way of converting your single-tablespace InnoDB database into a file-per-table one, without the pain of exporting and importing everything at once.

In previous part we put aside the issue of foreign keys. We address this issue now.

What if my InnoDB tables have foreign keys?

MyISAM does not support them, so you can't just ALTER an InnoDB table to MyISAM and back into InnoDB, and expect everything to work.

Alas, this calls for additional steps (i.e. additional ALTER commands). However, these still fall well under the concept of "do it one table at a time, then take time to recover your breath and replication lag".

Save , drop and restore your …

[Read more]
Getting rid of huge ibdata file, no dump required

You have been told (guilty as charged), that the only way to get rid of the huge InnoDB tablespace file (commonly named ibdata1), when moving to innodb_file_per_table, is to do a logical dump of your data, completely erase everything, then import the dump.

To quickly reiterate, you can only delete the ibdata1 file when no InnoDB tables exist. Delete this file with an existing InnoDB table, even a table in its own tablespace, and nothing ever works anymore.

The problem with the dump-based solution

The impact of doing a logical dump is often overwhelming. Well, the dump may be tolerable, but the restore is much longer. The real pain is that you can't do …

[Read more]
Resilient Services – Resilient Infrastructure – Site Reliability Engineer

Modern internet infrastructure are complex.  Components and services are prone to failure.  Resiliency involves building redundancy, best practices and processes into your architecture to make you able to bend and not break.

  • Migrating to cloud service providers
  • Rearchitecting and refactoring applications to scale
  • Scaling the database tier - MySQL and Oracle
  • Building redundancy into every layer
  • Deploying object caches - memcache
  • Deploying page caches - varnish
  • Migrating to Innodb - transactional storage engine
  • Infrastructure design
  • Infrastructure automation
  • Disaster Recovery
  • Business Continuity with cloud deployments

Call or Skype us in New York City +1-212-533-6828

MySQL - the best stored routine is the one you don't write

At Fosdem 2010, already two weeks ago, I had the pleasure of hearing Geert van der Kelen explain the work he has been doing on connecting MySQL and Python. I don't know anything about Python, but anybody that has the courage, perseverance and coding skills to create an implementation of the the MySQL wire protocol from scratch is a class-A programmer in my book. So, I encourage everyone that needs MySQL connectivity for Python programs to check out Geert's brainchild, MySQL Connector/Python.

In relation to MySQL Connector/Python, I just read a post from Geert

[Read more]
MySQL: Refactoring a Stored Function

Hi All!

I was just reading PlanetMySQL and noticed Mike Hillyer's recent post on a user-friendly age function for MySQL. Basically, this function accepts two DATETIME values and returns an indication of the time between the two dates in the form of a human-readable string. For example:

mysql> select  TimeDiffUnits('2001-05-01', '2002-01-01')
+-------------------------------------------+
| TimeDiffUnits('2001-05-01', '2002-01-01') |
+-------------------------------------------+
| 8 Months |
+-------------------------------------------+
1 row in set (0.00 sec)



Just for fun, I decided to try and refactor it, and I'm …

[Read more]
MySQL reengineering project

Here's another chapter of the MySQL evolution saga.

We know that MySQL today, although hugely popular and effective, has many shortcomings. A Refactoring effort has been announced, after a few months of internal discussions.

The effort is open to external contributions. There is a mailing list for discussing the "what" and the "how" of the new path.

The goals of the project are basically

  • Modularity. Make it easier to add new features without breaking existing ones.
  • Pluggability. Make it easier for third parties to add functionality.
[Read more]
MySQL reengineering project

Here's another chapter of the MySQL evolution saga.

We know that MySQL today, although hugely popular and effective, has many shortcomings. A Refactoring effort has been announced, after a few months of internal discussions.

The effort is open to external contributions. There is a mailing list for discussing the "what" and the "how" of the new path.

The goals of the project are basically

  • Modularity. Make it easier to add new features without breaking existing ones.
  • Pluggability. Make it easier for third parties to add functionality.
[Read more]
MySQL reengineering project

Here's another chapter of the MySQL evolution saga.

We know that MySQL today, although hugely popular and effective, has many shortcomings. A Refactoring effort has been announced, after a few months of internal discussions.

The effort is open to external contributions. There is a mailing list for discussing the "what" and the "how" of the new path.

The goals of the project are basically

  • Modularity. Make it easier to add new features without breaking existing ones.
  • Pluggability. Make it easier for third parties to add functionality.
[Read more]
Showing entries 1 to 10 of 13
3 Older Entries »