DEV Community: Ben Ramsey

Testing the PDO_ODBC driver on macOS

Ben Ramsey — Wed, 12 May 2021 23:27:23 +0000

I response to Christoph’s comment on PR #6935, I wanted to check to see exactly what PHP returns when calling PDO::getAttribute() on PDO_ODBC with PDO::ATTR_SERVER_INFO and PDO::ATTR_SERVER_VERSION. Looking at the code, I could tell that it breaks and returns a 0. I wasn’t sure how it reacted beyond that, and I wanted to test it in PHP to see what would happen.

To do this, I needed to be able to connect to a database using ODBC on macOS. Since I primarily use MySQL or PostgreSQL, I haven’t used ODBC to connect to a database in almost 20 years.

My PHP build already had PDO_ODBC installed, so I didn’t need to rebuild it.

$ php -m | grep -i odbc
odbc
PDO_ODBC

Next, I checked to see whether unixODBC was installed, and I wanted to connect to a MariaDB server, so I installed the unixodbc and mariadb-connector-odbc packages with Homebrew. (It turned out that unixodbc was already installed on my system through Homebrew.)

brew install unixodbc mariadb-connector-odbc

From here, I created a temporary file with the following contents (I named it mariadb-odbc.ini).

[MariaDB ODBC 3.1 Driver]
Description = MariaDB Connector/ODBC v.3.1
Driver = /usr/local/lib/mariadb/libmaodbc.dylib

The libmaodbc driver is provided by mariadb-connector-odbc, and the path to the Driver is based on where Homebrew put it, so if you’re following along and attempting to do the same, double-check the location on your system.

Then, I imported the driver configuration using odbcinst, which comes with unixODBC. Check the odbcinst documentation for more information about the above INI file format.

odbcinst -i -d -f mariadb-odbc.ini

This adds the configuration to /usr/local/etc/odbcinst.ini.

I then used Docker to create a MariaDB container that I could connect to using the ODBC driver.

docker run -p 3306:3306 --name mariadb -e MYSQL_ROOT_PASSWORD=password -d mariadb:latest

With the container up and running, I launched PsySH and started entering expressions.

=> $dsn = "odbc:Driver={MariaDB ODBC 3.1 Driver};Server=127.0.0.1;Database=mysql;User=root;Password=password;Option=3;"

>>> $pdo = new PDO($dsn)
=> PDO {#3907
     inTransaction: false,
     attributes: {
       CASE: NATURAL,
       ERRMODE: EXCEPTION,
       PERSISTENT: false,
       DRIVER_NAME: "odbc",
       ORACLE_NULLS: NATURAL,
       CLIENT_VERSION: "ODBC-unixODBC",
       STATEMENT_CLASS: [
         "PDOStatement",
       ],
       DEFAULT_FETCH_MODE: BOTH,
     },
   }

>>> $pdo->getAttribute(PDO::ATTR_SERVER_INFO)
PDOException with message 'SQLSTATE[IM001]: Driver does not support this function: driver does not support that attribute'

>>> $pdo->getAttribute(PDO::ATTR_SERVER_VERSION)
PDOException with message 'SQLSTATE[IM001]: Driver does not support this function: driver does not support that attribute'

So, there we go. PDO::getAttribute() throws a PDOException when it doesn’t support an attribute.

Thanks to Calvin Buckley, these attributes will no longer throw exceptions and will instead return actual values in PHP 8.1.

>>> $pdo->getAttribute(PDO::ATTR_SERVER_INFO)
=> "MariaDB"

>>> $pdo->getAttribute(PDO::ATTR_SERVER_VERSION)
=> "10.05.000009"

Using CLion with php-src

Ben Ramsey — Mon, 10 May 2021 17:08:02 +0000

I’ve cloned and built php-src numerous times over the years, on a variety of platforms, but I’ve never worked with it in an IDE. A long-time Vim user, I’ve only begun using PhpStorm over the last year and a half, after seeing how IntelliJ helped me easily navigate an open source Java project. So, in setting up php-src for release management tasks, I wanted to give CLion a try.

Getting php-src ready for CLion

When opening existing source code or cloning a repo with CLion, it assumes the project already supports CMake tooling for builds. For someone new to C and using a project that doesn’t use CMake, this can be confusing and frustrating. Since php-src isn’t a CMake project, CLion will display warnings at the top of every open file, saying that a “CMake project is not loaded,” giving you the option to select or generate a CMakeLists.txt file. You can try to do this for php-src, but there’s a better way.

CLion also supports JSON compilation databases. To generate one and have CLion recognize php-src as a compilation database project, you’ll need to do the following before opening php-src in CLion. If you’ve already opened it in CLion, that’s okay. Delete the .idea/ folder that CLion creates, and then do the following. (I could not figure out a way to make CLion recognize the compilation database if I had already opened the project in CLion. It seems the compilation database must exist the first time you open the project in order for CLion to recognize it.)

You’ll need the compiledb Python tool to generate the compilation database. It wraps the make command, so when you run it with make, it captures all the sources and creates a compile_commands.json file. Then, when you open the project in CLion for the first time, it will recognize your project as a compilation database project.

pip install compiledb

git clone https://github.com/php/php-src.git ~/repos/php/php-src
cd ~/repos/php/php-src
./buildconf
./configure \
    --prefix=$HOME/builds/php/8.1.0-dev \
    --disable-all \
    --disable-cgi \
    --enable-debug \
    --enable-zts

compiledb make

As you can see here, I use compiledb to call make. In this way, compiledb can learn about all the sources for your build.

You may also pass -jN to make, where N is the number of CPU cores your system has available. This will greatly speed up compilation.

You can run nproc to find out how many cores you have. On my system, I have 12 cores, so I run the command like this:

compiledb make -j12

In my example, I pass --prefix to configure, but this isn’t necessary since I’m not going to run make install. Once make has finished building PHP, you can find the newly-built PHP CLI at sapi/cli/php.

$ ./sapi/cli/php -v
PHP 8.1.0-dev (cli) (built: May  6 2021 18:27:37) (ZTS DEBUG)
Copyright (c) The PHP Group
Zend Engine v4.1.0-dev, Copyright (c) Zend Technologies

$ ./sapi/cli/php -m
[PHP Modules]
Core
date
hash
json
pcre
Reflection
SPL
standard

[Zend Modules]

Setting up CLion to build and run PHP

Now that php-src has a compilation database (which needs to be updated each time you change your build with configure or if you add new sources that get included in make), you can open it in CLion.

Launch CLion to get to the welcome screen and choose to open a project from existing sources.

Browse to your php-src folder and, rather than selecting the folder to open, select the compile_commands.json file that compiledb generated.

When CLion prompts you, choose to open it as a project.

CLion will now open the project and inform you that it successfully imported the compilation database project.

With CLion open, you’ll now create custom build targets for make and make clean.

Open CLion Preferences and go to Build, Execution, Deployment -> Custom Build Targets. Create a new build target, named something like “Build PHP.” Then, next to the empty Build and Clean fields, click the more button (with three dots). This will open an External Tools window. Use the +-button here to create two external tools.

I named the first one “Build with Make.” The program is make and I added -j12 to the arguments for a faster build (see earlier). You might also consider using compiledb as the program, with make -j12 as the arguments.

I named the second tool “Clean with Make” and used make as the program and clean as the argument.

Now, you can click OK to close these windows and the External Tools window, and select the proper tools to use with your Build PHP target.

Finally, you’ll want to create a custom run/debug configuration. To do this, go to Run -> Edit Configurations….

Use the +-button to create a new configuration and choose Custom Build Application from the menu that appears. I named my configuration “Build PHP” and I chose my “Build PHP” target (created earlier) from the Target dropdown list. For the executable, I entered the path to the PHP CLI built by this project (remember, it’s at sapi/cli/php). Last, I checked “Redirect input from” and entered the JetBrains variable $FilePrompt$ . In this way, whenever you chose to run PHP from within CLion, it will prompt you with a file dialog to execute through the PHP interpreter. This lets you select a PHP script to run and test/debug whatever feature you’re working on.

Now, click the hammer icon (🔨) or select Build -> Build Project to build PHP, or select Build -> Clean to run the make clean command.

If you click the play icon (▶️) or choose Run -> Run ‘Build PHP’, it will prompt you to select a file and run that file as a PHP script. In the following, I’ve selected one of the .phpt tests to execute this way.

Step debugging through php-src

One of the primary reasons I wanted to use an IDE to work with php-src is for the debugging tools. With everything set up as described earlier, I’m able to run a PHP script and break on breakpoints in the C source code.

As an example, I created a PHP script named date-debug.php and added the following code to it.

<?php
echo date('Y-m-d H:i:s', time());

Then, I opened ext/date/php_date.c and placed a breakpoint in the php_date() function. You can see the breakpoint in the following screenshot. I placed it right after the ZEND_PARSE_PARAMETERS block.

When you click the debug icon (🪲) or choose Run -> Debug ‘Build PHP’, CLion will prompt you to select a file, just like it does when when you click the play icon, as described earlier. When I choose the date-debug.php file, it begins executing it and then stops at the breakpoint in the C code, which happens to be the code called when using the PHP date() function. As you can see, I’m now able to examine the memory and variables in this function, including the zvals.

I’m a release manager for PHP 8.1!

Ben Ramsey — Sun, 09 May 2021 18:58:14 +0000

My permanent blog at benramsey.com is in a state where I am unable to update it. It’s a long story that involves versions of Ruby gems removed from the repository, trapping me in a tangled web of Jekyll dependency hell, and I haven’t had the stomach to unravel it. In the meantime, I’ll be posting here at dev.to/ramsey.

Last year, I tossed my hat in the ring to volunteer as a release manager for PHP 8.0, but I lost the vote to Gabriel Caruso, who has shown himself to be a very capable RM for the 8.0 series (congrats, Gabriel, and great work!). This year, when Sara announced the RM selection process for PHP 8.1, I almost decided against volunteering, but I finally decided to go for it, and I’m glad I did.

Each set of release managers is usually comprised of a veteran RM and a rookie. This year, when Joe Watkins volunteered as the veteran RM, he asked to take on two rookies. As a result, Patrick Allaert and I were both selected as rookie RMs for the 8.1 series.

PHP release managers manage the release process, create a roadmap for the release, facilitate discussions and decisions about what goes into a release, package the releases, etc. It’s a commitment of about three-and-a-half years, as they shepherd their minor version from alpha to beta to RC to GA to active support to security support and, finally, end-of-life. The supported versions page at php.net provides a good overview of this cycle.

You can read more about the PHP release process here:

Additionally, Eric Van Johnson has published a three-part interview in php[architect] magazine with PHP 8.0 release managers Sara Golemon and Gabriel Caruso. They go into a lot of the specifics.

Thank you so much to everyone for entrusting me to serve as one of the release managers for PHP 8.1! I look forward to working with Joe and Patrick over the next three-and-a-half years.

Thoughts on Software Architecture

Ben Ramsey — Thu, 18 Apr 2019 13:51:43 +0000

I originally posted this as a thread on Twitter in response to a recent #DevDiscuss topic. I'm reposting here to preserve these thoughts and for others to easily refer to it.

Software architecture concerns itself with how the software is built, including high-level design and technical standards, as well as coding standards, tools, platforms, etc.¹

A software architect is a software developer who has become an expert in these things through extensive experience practicing them and learning from others.

A software architect (as a role) is a leader in the organization, helping the team turn a problem domain into software. They are able to grasp the concepts of the domain and communicate how to represent them in code. Additionally, they work with the team to set standards and develop practices that will ensure the quality of the software created and the long-term maintainability of the code. They balance purity with pragmatism, considering the business goals and priorities—and they articulate the risk to the business when sacrificing quality/purity for accelerated timelines.

I believe a software architect should be a mentor, using their experience to teach others how to create the best software they can. This involves in-depth code reviews and pair programming, among other teaching techniques. Good software architects are humble and patient. They don’t berate or belittle their team for not yet grasping concepts that they see clearly. Instead, they use these moments as teaching opportunities.

Many see coding as formulaic as algebra equations. Software developers are natural problem-solvers, often seeing a code solution based on a formula before fully understanding the problem. Software architecture is different. There is no formula for it. There are recurring patterns seen across problem domains, and Martin Fowler has cataloged many, but his book Patterns of Enterprise Application Architecture cannot be treated as a formula by filling in the blanks and generating the code. It doesn’t work that way.

Learning to design software from an architectural perspective is an exercise in grokking² the problem, taking a Zen-like approach to perceiving its true nature. To do this, you must exercise restraint so you don’t cloud your mind with thoughts of the solution before you fully understand the problem.