Michael Dyrynda has a new post to his site showing the Laravel users out there how to share a database between your applications. In his case one of the applications is a legacy app and the other is a newer Laravel application.

As a contractor, I had a sanitised copy of the database, and I managed to reverse engineer the Eloquent models from the database schema, creating factories along the way, in order to be able to write tests for the members application.

In late 2017, we started migrating our CRM to Laravel as well, in order to modernise the code base a bit, give it a standard structure, and make it easy to make changes to it moving forward. Now that we had two Laravel applications, we started looking at how best to share data between them.

He starts by talking about reverse engineering the models from the database structure and the use of migrations to manage the database schema. In the end he created a stand-alone tool, Nomad, that helps to keep things in sync between the two databases. He includes examples of it in use and how it helped to keep the database in sync despite permissions issues and connection problems. He also mentions how they used it to take care of some testing issues, database configuration changes and how to use it in a continuous integration pipeline.

In this new post to his site Leonid Mamchenkov talks about validating JSON content sent to your application to ensure it matches a JSON schema definition.

GitHub was rather slow yesterday, which affected the speed of installing composer dependencies (since most of them are hosted on GitHub anyway). Staring at a slowly scrolling list of installed dependencies, I noticed something interesting.

Of course, I’ve heard of the seld/jsonlint before. It’s a port of zaach/jsonlint JavaScript tool to PHP, written by Jordi Boggiano, aka Seldaek, the genius who brought us composer dependency manager and packagist.org repository.

But JSON schema? What’s that?

From there he gets into a high level definition of what JSON schema is and the similarities it has to XML's structure. He then links to a PHP package that can help with the validation and how to use it (defining a simple JSON file, a schema and the code to perform the evaluation).

On the JoliCode.com blog there's a post sharing the experience of writing an API client with PHP including some advice to those out there considering doing the same.

My (love-)story with Docker started in December 2013, after having lost a 2 years long battle against Chef. I had been attracted to Docker for a couple of months, and I finally made the switch the day when I learned that it was built on a REST API. This meant that I could control all my infrastructure from PHP, which is the language I’m most partial to.

After some research, I found the library docker-php built by ubermuda, but, like all the things around Docker at that time, there was only a very limited support of the API. Like any decent developer (yes, it’s a troll), I started to write pull requests to fulfill my needs, and it was both the greatest and the worst thing that happened to me.

The post starts off with a brief history of PHP libraries working with HTTP requests (and the difficulties he had with Guzzle). This includes the fast pace that the library was changing at the time, making it difficult to keep the code maintained. He took a "step back" and decided to look more into HTTPlug and some changes to help bring it up to date. With that choice made, he got into the automation portion and using it work with the Docker API. He talks about some of the other technologies and tools he investigated along the way including Jane for working with JSON message schemas.

Maintaining an open source library is hard and takes time. However, these last years made me realize that we can control it, by moving features into other projects, trust people behind it, and by reducing the feature sets.

On the SitePoint PHP blog author Andrew Carter has shared a "quick tip" about using a disposable database in the testing of your Symfony-based applications.

Testing code that interacts with a database can be a massive pain. Some developers mock database abstractions, and thus do not test the actual query. Others create a test database for the development environment, but this can also be a pain when it comes to continuous integration and maintaining the state of this database.

In-memory databases are an alternative to these options. As they exist only in the memory of the application, they are truly disposable and great for testing. Thankfully, these are very easy to set up with Symfony applications that use Doctrine.

He talks first about the built-in functionality Symfony has to use different configuration files for different environments. This allows for easier testing in a more isolated setup than replicating development. He then shows how to use Doctrine with a SQLite in-memory database with a simple update to the config_test YAML configuration file. He also includes the code for a DatabasePrimer class that gets the Doctrine entity manager and executes the the schema tool to set up the schema in the database and "prime" it with any fixtures you might need.

Paul Jones has a post to his site looking at SQL schema naming conventions and some of his own thoughts on the matter. There's a lot of different camps of thought around naming, much less database ones, and he makes a few suggestions learned from his experience over time.

Several weeks ago I asked on Twitter for SQL schema naming conventions from DBA professionals. (I’m always interested in the generally-accepted practices of related professions; when I can, I try to make my work as compatible with theirs as possible.)

I got back only a handful of responses, representing MySQL, PostgreSQL, and DB2 administrators, really not enough for a statistically useful sample. Even so, I’m going to present their anonymized responses here, because they led me to work I had not previously considered at length.

He asked about things like singular vs plural names, primary key choices and naming of association tables. The uses the rest of the post sharing the responses he got from his questions with a good range of responses representing both sides of each question. He wraps up the post looking at what these answers mean to the average developer and the answers that Joe Celko and Simon Holywell have to say on the matter.

If you're a Codeception user, you'll find Matthew Turland's latest post interesting. In it he shares a way to customize database cleanup between the tests. Codeception handles it a bit differently that how PHPUnit's Db module does.

Recently, I was looking into ways to speed up the runtime of the test suite at Blopboard. We use the Codeception framework to write functional tests for our REST API, part of which entails putting the database into a known state using Codeception’s Db module. The behavior of this module is similar to that of the PHPUnit Database extension with one exception: where PHPUnit only truncates tables and leaves their schemas intact, Codeception removes the database structure and expects the SQL dump it uses to recreate it between tests. I must admit to not understanding this design decision of Codeception, nor attempts to clarify it.

He admits that his solution is "a bit hacky" but it does work to truncate the table rather than drop the entire schema and wait for a rebuild. His "DbHelper" class is used in place of the Db module. He traced through the execution path of the Db module and found a "hook" where he could override the "cleanup" method to prevent the schema drop and replace it with a truncate. He also includes code for a suggested addition to Codception that would handle the same thing in a more integrated way.

In his latest post to his site Chris Jones shows you how to update the Zend Framework 2 tutorial app (quickstart) to make it work with an Oracle database instead.

This post shows the changes to the ZF2 tutorial application to allow it to run with Oracle Database 11gR2. [...] The instructions for creating the sample ZF2 application are here. Follow those steps as written, making the substitutions shown [in the rest of the post].

The full schema definition is included in the post, complete with the same sample data as the tutorial. He includes the updates you'll need to make to the database configuration for the OCI8 connection and changes to the code to accommodate the Oracle data format (mostly uppercasing everything).

Danne Lundqvist has a new post where he shares a bit of code he's written to "come to grips" with an existing XML structure.

Very often I find myself writing input filters for large XML files using PHP. Common enough task; and PHP offer a great variety of tools to do this effectively depending on the situation. Unfortunately, almost as common is the lack of documentation for the aforementioned XML files. [...] I have looked around for a simple tool but I didn’t really find a tool that gave me the quick and dirty overview I wanted. A year or so ago I finally wrote a small PHP class to analyze large XML files.

He includes an example XML file, the HTML output of the parsing and a sample of how to use the class to parse and output the XML structure, complete with some CSS.

On his blog today Sameer Borate has a new post looking at using Doctrine DBAL to make schemas rather than having to make them by hand each time (can be very useful for reloads with fixtures).

A tedious task during web development is that of database schema creation. A schema containing a few tables comprising of a small set of rows is quick, while that containing dozens of tables and large numbers of columns is a tedious process. I usually resort to a small php script with some regular expression tossed in to automatically create a schema from a text file definition. But that is a little buggy as I’ve to manually add the indexes and other small things. Now that Doctrine has released a DBAL library, this will provide a nice ability to automatically create sql schemas.

He introduces the DBAL abstraction layer and includes a basic script to create a schema for a MySQL database, manually adding the columns and setting up things like primary keys and foreign key constraints. He also includes the SQL statements that it will generate and execute on your Doctrine-based connection.

In this new post to his blog today Gonzalo Ayuso looks at how he's set up a system that uses PHP to synchronize their PostgreSQL databases' schemas when things changed.

We create source code at development server and push the changes to production. It’s really easy to keep synchronized all our code. But with databases it’s different. [...] It’s a recurrent problem working with databases. We create database objects (tables, views, ..) in the development server and when our application is ready to go live we push the changes to production server. If we are smart developers we save all database scripts in a file and when we deploy them to production we execute the script.

He mentions tools like dbdeploy and phing to help make these migrations a bit more automatic. He needed something a little different though - a command-line script that would, based on an ini file, sync two or more databases. He's created the basic script that includes the actions to show the differences between the databases, a summary of the differences and an execution method to bring them into sync. He gives a basic example of how it would handle the sync between his example production and development databases.