OSdata.com

example source code
MySQL replacement in PHP

The old original MySQL API in PHP is depreciated, so it is only a matter of time before it disappears. It is urgent for web sites to change over to a more modern alternative.

Warning

This extension is deprecated as of PHP 5.5.0, and will be removed in the future. Instead, the MySQLi or PDO_MySQL extension should be used. See also MySQL: choosing an API guide and related FAQ for more information.

This web page describes a three step method for converting from the old to the new.

Building a game — open source code This is the actual source code from a new web game. See the game at thissideofsanity.com and read how this was built starting at example code.

This is example code from the SlamZee project and This Side of Sanity, released under Apache License 2.0.

Licensed under the Apache License, Version 2.0 (the “License”); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

This narrative uses anchor links so that you can follow the building of this software in chronological order. Go to software explanation to start reading. Go to thissideofsanity.com to see the working software.

example source code
MySQL replacement in PHP

The old original MySQL API in PHP is depreciated, so it is only a matter of time before it disappears. It is urgent for web sites to change over to a more modern alternative.

Warning

This extension is deprecated as of PHP 5.5.0, and will be removed in the future. Instead, the MySQLi or PDO_MySQL extension should be used. See also MySQL: choosing an API guide and related FAQ for more information.

This web page describes a three step method for converting from the old to the new.

step one:
convert in place

This first step is technically horrible and will actually add a little to your technological debt, but it will keep you from going off-line at a fast approaching revision release of PHP. Please make sure that you follow through with the second and third steps and really solve your underlying problems.

The mysqli_ set of functions have both procedural and object-oriented versions, and the procedural versions map fairly well with the depreciated mysql_ set of functions.

The biggest difference is that new mysqli_ makes use of link identifier resource. The mysqli_connect procedural function returns the link identifier resource upon a successful data base connection. The rest of the new mysqli_ procedural functions make use of the identifier link to know which database to operate on.

In general, the mysqli_ procedural functions have the same parameters and same order as the older, depreciated mysql_ functions, except that a new parameter (the identifier link) is added, usually at the beginning of the parameter list.

This gives us our very ugly, very bad coding, but quick and easy method for conversion.

Create a global variable to hold your link identifier resource. Global state is always a dangerous side effect waiting to mess you up. So, remember, this is only the first step. This is temporary. If you connect to multiple databases, create a different global link identifier resource variable for each database.

$mysqli_link = NULL;

Now, go to every function, procedure, object, method, etc. that incldues any calls tot he old mysql_ API and add a global declaration to your link identifier resource, so that you can use it inside your local function, object, etc.

global $mysqli_link;

Now, replace your old mysql_connect calls with a modern mysqli_connect call, saving the link identifier resource in your global.

You will find an example for “easy migration from the old mysql extension” in the official online PHP documentation at www.php.net/manual/en/mysqli.quickstart.dual-interface.php.

Now go through your code and replace the old mysql_ calls with modern procedural mysqli_ calls. You will almost always find the comparable function. If you used a link identifier previously, move it to the beginning of the parameter list. If you left off the optional link identifier (a common practice), then you need to add the new identifier link to the beginning of your parameter list.

In some rare cases you will find that there is no easy corresponding mysqli_ function for your old mysql_ function. You will have to examine the code and search through the new mysqli_ API library and figure out a more modern solution.

At this point you have salvaged your project and are immune from sudden failure when your PHP version gets updated.

On the other hand, you have made your software less reliable. Therefore, you will want to continue on to the next two steps. Please. For your own good.

step two:
convert to object oriented programming

You will want to convert from the old procedural style programming to modern object oriented programming. You can choose between a vendor-specific API (such as mysqli) or a platform neutral API (such as PDO, or PHP Data Objects). Each approach has its advantages and disadvantages. If you use vendor-specific features of MySQL, then you are probably locked in for now, although this step would be the appropriate time to break out. If you don’t currently use any vendor-specific features and don’t have any upcoming plans to do so, then this is a great time to move to a platform-independent method, allowing you the freedom to change hosting companies, servers, or database package whenever needed.

It is possible to write procedural code in object-oriented languages. You just thinly disguise your procedural code in an object-oriented wrapper. Don’t do this. Your technological debt will increase and eventually this will come back to haunt you, possibly closing you down.

So, you are going to create classes to handle all of your persistent data operations. You are going to separate these from your working code, just as you should separate presentation from functionality. If you haven’t done that either, you need to do it now. You need the various conceptual patterns in your software separated to gain the full advantages of object-oriented programming.

There is a lot of work to do here, especially if you have a large existing software project. Because of the nature of PHP (as a beginner’s language), it is common to see PHP projects become a snarled mess. The good news is that PHP actually provides all of the tools you need for quality, well-organized object-oriented software.

You may want to study the Gang of Four design patterns before undertaking this step. While there are legitimate professional criticisms of the Gang of Four, it is worth learning and understanding their ideas. You can then either accept or reject their ideas from a position of knowledge.

In particular, you may want to pay attention to the Bridge, Adapter (Wrapper or translator), and Mediator patterns.

step three:
Test Driven Development

In the previous step, you converted to real object-oriented programming. In particular, you separated all of your persistent data operations (database work) from all other software.

Now that you have achieved that step, you can clean up your classes without causing any harm or introducing errors to any other part of your software.

This means that you can convert your persistent class or classes to test Driven Development safely. Everything will continue to work because the changes are isolated from all other work.

Here is the basic methodology for Test Driven Development (TDD).

Pick one isolated simple task. Something that you can completely comprehend and understand in isolation.

Create a unit test for that task. The test should initially fail because you haven’t yet written any code for it. Always confirm that the test fails.

Now create a class that solves that one problem. No other additional problems. Just the one.

Run the unit test and make sure that your new class works properly. Run all of your unit tests and make sure you didn’t break something that was already working.

Buff up your unit test. Look carefully at your unit test and make sure it really does test the task at hand. Run bad data and make sure your test fails. Think of every corner case that you can. be as thorough as possible.

Refactor your new class. Your first goal was simply to get the thing working properly. Now really examine it and polish it and make it the best you can. Of course, make sure that all of your unit tests still pass after refactoring.

You may discover as you refactor that it may become obvious that your class includes too many different ideas and you may need to break it into additional classes (with unit tests for each new class).

Now, think of the next simple step that needs to be done on your project and repeat the TDD pattern (build test that fails, build a class that passes the test, refactor).

Ideally you should be able to push through the TDD process fairly quickly. With practice, you should be able to do each new roudn of TDD in 30 seconds to a few minutes. If it takes longer (after you’ve become accustomed to this approach), then you are probably making your classes too big.

When properly done, TDD provides a fast and reliable method for building large, complex software. You have a unit test for everything. Everything is simple in isolation.

return to explanation of source code

OSdata.com is used in more than 300 colleges and universities around the world

Find out how to get similar high web traffic and search engine placement.

OSdata.com is used in more than 300 colleges and universities around the world

Read details here.

Tweets by @osdata

A web site on dozens of operating systems simply can’t be maintained by one person. This is a cooperative effort. If you spot an error in fact, grammar, syntax, or spelling, or a broken link, or have additional information, commentary, or constructive criticism, please e-mail Milo. If you have any extra copies of docs, manuals, or other materials that can assist in accuracy and completeness, please send them to Milo, PO Box 1361, Tustin, CA, USA, 92781.

Click here for our privacy policy.