On the Laravel News site they've posted the latest tutorial in their series covering the creation of a translation package. In this latest article they cover the creation of the database driver to replace the previous file-driven content handling.

In the previous article of the series, we talked about how to handle missing translations, which brings us very close to making the package feature complete. To finish up the build phase of this series, we will discuss how we go about adding a database driver.

Thanks to defining the interface for the data handling previously, redefining the handler for the database is simpler. He includes the code for:

• the migrations to create the languages and translations tables
• the models for both tables and their relations to each other
• creation of the database driver using the interface

His code includes methods for getting either single or multiple translations including fetching them by language. He then updates the "resolve" method to allow defining the driver to use in the configuration rather than being hard-coded.

In a recent post to his site Jonathan Reinink has written up a guide to using dynamic (Eloquent) relationships in Laravel applications by making use of subquery functionality. In it, he shows how to make use of the selectSub method to select additional information in a single query versus having the overhead of custom, hard-coded relationships.

When building web apps that interact with a database, I always have two goals in mind: keep database queries to a minimum [and] keep memory usage to a minimum. These goals can have a drastic impact on the performance of your app.

Developers are typically pretty good at the first goal. We're aware of N+1 style problems, and use techniques like eager-loading to limit database queries. However, we're not always the best at the second goalkeeping memory usage down. In fact, we sometimes do more harm than good trying to reduce database queries at the expense of memory usage.

He starts off with the challenge he's trying to solve: gathering login information for users in a performant way. He includes the schema for the users and logins table and shows the code of how a normal relationship select might look to get login information for each user (creating an N+1 issue).

To help solve the issue, they try caching the last login information but realize they can do better - this is where subqueries come in. They provide an example of using the selectSub method to get the login information, mapping it to a macro for easier use and defining scopes. Finally, the tutorial shows how to use this method to select information via dynamic relationships. It also talks about lazy-loading issues and if the same thing could be accomplished with a "has one" relationship.

Matthias Noback has kicked off a new series of posts on his site covering the use of the repository design pattern in different situations. In this first post he focuses on "test driving" classes for handing database queries and their results.

A test for a repository can't be a unit test; that wouldn't make sense. You'd leave a lot of assumptions untested. So, no mocking is allowed.

[...] But how do you test everything that is going on in a repository? Well, I found out a nice way of doing so, one that even allows you to use some kind of test-driven approach. In this article I'll cover one of the two main use cases for repositories: querying the database, and returning some objects for it. The other use case - storing and loading objects - will be discussed in another article.

He starts by getting everyone on the same page with a definition of a "query" and how it relates back to a repository class. He then walks through the process of how to test the class, first as a general "get all" query then with a check on the "active" state. Once the test goes green (successful), he adds more variations to both the tests and fixtures. There's not a lot of code examples in this post but it does show some good concepts to get you headed down the right path.

On the Happyr.com Developer blog Tobias Nyholm has written up a tutorial showing how you can use functionality included in the Symfony framework to define access control rules in a database using voters and values stored in the database.

I was recently at a PHP conference in Odessa where I met many great developers. One of them asked me a question, that the answer was not obvious. His use case was that he wanted to use Symfony's Access Control configuration to restrict access in his application. But he also wanted to configure the rules dynamically.

Since all the configuration in Symfony is cached with the container for performance reasons, we could obviously not allow a use a database to somehow “print” new configuration. We need to do something smarter.

Voters are a part of the Symfony security component and are set up as a service in the Symfony DI container. When a route is defined in the access_control section, the matching voter is called and the access granted/denied state is determined by values from the token and subject provided (from the database).

On the Sticher.io blog Brent has written up a post covering the use of MySQL views in Eloquent, the database ORM that's included with the Laravel framework.

MySQL views are a way of storing queries on the database level, and producing virtual tables with them. In this post we'll look at why you want to use them and how they can be integrated in Laravel with Eloquent models.

If you're already convinced of the power of MySQL views, or just want to know how to implement them in Laravel, you're free to skip ahead.

For those not familiar with the concept of "views" in MySQL, he spends a little time explaining what they are and what benefits they bring to the table. This includes a code example of a migration to create one and how something similar could be achieved with event hooks on a Laravel model. He then gets into the use of the views with Laravel, refactoring a more complex SELECT query into a view and creating/removing it using the same migration methods as any other table in the database.

Matthias Noback has written up an article on his site covering a tool that's common in many web applications, especially for testing: fixture data. In the post he makes some suggestions about effective ways to use them to provide more "real world" results for tests.

System and integration tests need database fixtures. These fixtures should be representative and diverse enough to "fake" normal usage of the application, so that the tests using them will catch any issues that might occur once you deploy the application to the production environment. There are many different options for dealing with fixtures; let's explore some of them.

He makes four suggestions of ways to handle fixtures:

1. Generate them the "natural" way via interaction with the application and taking a snapshot of the data.
2. Generate them at runtime for the tests, reloading them each time
3. Manual insertion of custom data into the database for all tests
4. Manual insertion of custom data into the database for each test case

He finishes the post by asking a question for those considering using fixture data: do you need them at all? Testing should be isolated from external sources so maybe they're not really needed...

In a new post to his site site Joseph Silber shows you how, when using Eloquent in a Laravel application, to decouple your application from your database by removing hard-coded class names on polymorphic relationships.

Polymorphic relations let you set up a relationship between many different model types, without the need for extra tables. This works by storing the "morphable type" (explained below) in the database, in addition to the morphable type's ID.

By default, the morphable type stored in the database is the model's full class name. While this works, it tightly couples your database to your PHP application. Let's look at how we can instruct Eloquent to use more generic values for these morphable types.

He starts in with a "short refresher" on polymorphic relationships and what Eloquent models look like for a simple customer-to-address relationship. He then talks some about the "morph" type and how Eloquent stores the name of the relating model directly in the record (like AppCustomer or AppWarehouse). He shows how to customize the morph type to map the types to values in a morphMap setting to remove the need for those hard-coded class names. He wraps up the post answering the question many ask: "why doesn't Eloquent do this automatically?"

Matthias Noback has a post to his site today covering the use of Doctrine with domain-driven design as it relates to the definition and creation of the entities in your system.

As I discovered recently, you don't need an edge case to drop Doctrine ORM altogether. But since there are lots of projects using Doctrine ORM, with developers working on them who would like to apply DDD patterns to it, I realized there is probably an audience for a few practical suggestions on storing aggregates (entities and value objects) with Doctrine ORM.

He starts the article off by making a recommendation when building out your domain and entities: don't build with the ORM in mind. Its easy to think that entities and ORM models are the same thing, but he recommends defining them first and then figuring out how to work them in to the model structure. Eventually storing them and their state will have to be considered but that shouldn't influence the design. He illustrates with simple Line and PurchaseOrder entities and how to modify the base classes so they can be managed by Doctrine. He also covers some of the other concerns of making the transition over from entities to models in Doctrine (constraints, custom DBAL types, etc). He finishes the post covering annotations, the "one transaction only" DDD idea and value objects.

Rob Allen has continued his series of posts covering the use of PHP on the OpenWhisk platform. In his latest tutorial he shows how to use dependency injection for use in "non-trivial PHP applications".

Any non-trivial PHP applications use various components to do its work, from PDO though to classes from Packagist. It’s fairly common in a standard PHP application to use Dependency Injection to configure and load these classes when necessary. How do we do this in a serverless environment such as OpenWhisk?

This question comes up because we do not have a single entry point into our application, instead we have one entry point per action. If we’re using Serverless to write an API, then we probably

He uses a common connection type - PDO to a database - to illustrate a method for injecting dependencies in a serverless application. In his example, he starts with a simple script that returns a set of "todo" items from the database (with the PDO connection code embedded in it). Using dependency injection is a better way to manage that PDO connection so he shows how to update it to use the Pimple DI container and inject it via the constructor to make it available to the rest of the application.

On the Symfony Finland site they cover a recent announcement from MySQL about the release of their latest version: MySQL 8.0. In this post they cover some of the new features and performance improvements that come with this new version.

The MySQL development team has announced the General Availability of the MySQL 8.0.0 Open Source database.

This is the version following MySQL 5.7 that was released in late 2015 with interesting features like extensive JSON field support. Plenty of work has gone into this version as well and in an introductory post goes in-depth into all the enhancements.

The post includes a listing of eight topics (ironically) for the new updates including:

• Support for Window functions, Common Table Expressions, NOWAIT and SKIP LOCKED, Descending Indexes, Grouping, Regular Expressions, Character Sets, Cost Model, and Histograms (SQL)
• Geography support. Spatial Reference Systems (SRS), as well as SRS aware spatial datatypes, spatial indexes, and spatial functions.
• Remote management, Undo tablespace management, and new instant DDL.
• OpenSSL improvements, new default authentication, SQL Roles, breaking up the super privilege, password strength, and more.

Check out the rest of this post for more of the overview or MySQL's official announcement for the full details.