Truncated by Planet PHP, read more at the original (another 29493 bytes)

One of my pet peeves is using the database schema to validate data.

Several ways in which this normally happens:

• Specifying a column as “required”, e.g. email VARCHAR(255) NOT NULL
• Adding an index to force column values to be unique (e.g. CREATE UNIQUE INDEX email_idx ON users(email))
• Adding an index for foreign key integrity, including cascading deletes, etc.

Yes, I want data integrity too.
No, I don’t want to rely on the database for that.

I find it surprising that some years ago we decided that we shouldn’t write application logic in our database (e.g. stored procedures) because:

• They are not written in the same language as the rest of the project.
• They are not version-controlled (unless you jump through some extra hoops).
• They are not testable in isolation; you need an actual database to run them.
• They are “magic” because they are triggered implicitly.
• The code is vendor-specific.

Well, anyway, it’s clear that we don’t want them.

Yet, many of these concerns apply to validation at the database-level as well.
Except, with stored procedures we actually delegate some work to the database.
With validation, we usually duplicate the work.
We first validate in the code that a value has been provided and show a form error if it hasn’t.
Then we use an assertion in our model object to verify that a value is not null.
Then we save our object to the database, which again verifies that the value is not null.

Why do we do this?
Maybe because we want symmetry?
The model property is not nullable, so the column it’s mapped to should also not be nullable.
Maybe because we are more confident about the database than about our code?
In the code a validation might be skipped somehow, but we’ll always have that extra validation once the data ends up in the database.

Non-nullability

I think we don’t need the symmetry, nor the safe-guard.
Instead, we should put more trust in our application code and make sure everything is handled there.
No need for the “double bookkeeping” where you try to keep the nullability of your model’s properties in sync with the nullability of the database columns.
In my experience often a model property is nullable, but the database column isn’t, or vice versa.
This leads to the application blowing up for a nullability discrepancy between the code and the database.
We can reduce this risk by stopping the double bookkeeping.
Instead of defining non-nullability on database columns, let’s only define it in the code.
We always have to deal with non-nullability in the code anyway, since we want validation errors instead of SQL errors.
So, let’s just remove NOT NULL everywhere, hooray!

Unique indexes

Another interesting database-level validation technique is ensuring uniqueness, like in the case of the unique email address in the users table.
Apparently, we don’t trust the application here either, and leave the verification of an important rule to the database (we’ll talk later about how important it really is).
Given that the database supports a uniqueness check by means of adding an index we jump in and add it to every column we feel should be unique.
We then realize that we don’t want SQL errors when a user registers with a known email address.
We want form validation errors instead.
Then we introduce some more double bookkeeping so we can be user-friendly and protect our data integrity.

What if we only validate the uniqueness of the email address in the application code and not in the database?
We could end up with two records in the users table that have the same email address.
It’s unlikely that this will happen though, because the application always runs the uniqueness validation itself, by querying the table for an existing record with the provided email address:

if ($this->userRepository->containsUserWithEmailAddress($emailAddress)) { // show form error in the response
} else { // the data is valid $user = new User($emailAddress); $this->userRepository->save($user);
}

The only way we could end up with duplicate records is when two registration requests providing the same email address are being processed at the same time.
In that case, the first containsUserWithEmailAddress() may return false during both of these requests and the call to save() would result in two records with the same email address.
Again, it’s not very likely, but it could happen.
But what if it happens?
We just have to make sure it has no significant impact.

I think the biggest fear when having duplicate email addresses in the database is that someone might b

Truncated by Planet PHP, read more at the original (another 8982 bytes)

FleetOps—running a large fleet of apps and websites efficiently, securely, and predictably—is a challenge for every organization. One difficulty facing organizations managing multiple Drupal sites is keeping their dependencies current. For instance, each time a crucial security update is released, how many resources end up being spent making sure each site has properly been patched? How many team hours could be saved by automating dependency processes?
On Platform.sh, you can deploy your Drupal projects complete with a set of customized Source Operations that will automatically check for and apply updates using Composer to a development environment.

Byte-sized functional programming: Mapping out your data

Larry
27 July 2020 – 3:42pm

In this article, we look at the details of the PHP 7.2 release, including release date, EOL dates, features, improvements, deprecations, and performance.

Truncated by Planet PHP, read more at the original (another 17389 bytes)

The PHP team is pleased to announce the second testing release of PHP 8.0.0, Alpha 3. This continues the PHP 8.0 release cycle, the rough outline of which is specified in the PHP Wiki. For source downloads of PHP 8.0.0 Alpha 3 please visit the download page.Please carefully test this version and report any issues found in the bug reporting system.Please DO NOT use this version in production, it is an early test version. For more information on the new features and other changes, you can read the NEWS file, or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive. The next release will be Beta 1, planned for Aug 06 2020.The signatures for the release can be found in the manifest or on the QA site.Thank you for helping us make PHP better.

I wanted to share with you a free chapter from my latest book, “Advanced Web Application Architecture”.
I’ve picked Chapter 11, which gives a compact overview of all the design patterns that are useful for structuring your web application in a way that will (almost) automatically make it independent of surrounding infrastructure, including the web framework you use.

Chapter 11 is the first chapter of Part II of the book. In Part I we’ve been discovering these design patterns by refactoring different areas of a simple web application. Part II provides some higher-level concepts that can help you structure your application. Besides design patterns, it covers architectural layering, and hexagonal architecture (ports & adapters). It also includes a chapter on testing decoupled applications.

If you’re interested in this kind of topic, make sure to get a discounted copy using this link: https://leanpub.com/web-application-architecture/c/RELEASE_DAY.

Chapter 11: Key design patterns

This chapter covers:

• A catalog of design patterns
• Implementation suggestions
• A high-level design process based on these design patterns

11.1 Framework-inspired structural elements

Every framework comes with its own set of recognized element types.
For instance, Symfony developers learn to create controllers, entities, form types, Twig templates, Yaml configuration files, and so on.
Laravel developers also create controllers, but they need among other things: models, Blade templates, and PHP configuration files.
When you take a look at the directory structure of most web application projects, you’ll immediately notice the framework that’s been used.
Frameworks dictate your project structure.
And frameworks also invade your code.
This all sounds like frameworks are an enemy, instead of the helpful friend they presume to be, but this is a false contradiction.
In infrastructure code, frameworks are your friend.
In core code, they are not.

If frameworks determine the structure of your core code, you’ll end up with:

• Implicit use cases inside controllers,
• A domain model that’s coupled to its underlying infrastructure, and in general
• Code that’s coupled to the framework.

In Part I: Decoupling from infrastructure we’ve already seen many techniques to overcome these problems.
We were able to extract a use case from a controller by modeling it as a framework-independent service.
We extracted an entity from database interaction code.
And we decoupled code from the framework by using dependency injection everywhere, and by passing contextual information as method arguments.

In this chapter we take a closer look at the types of objects that were the result of decoupling from infrastructure.
Knowing more about the typical aspects of these objects will help you use them as building blocks instead of merely the result of refactoring activities.
By using these objects as “primitives” you can implement all of the application’s use cases, without even choosing a framework.
The framework will just be the finishing touch, the bridge between your application’s core and the outside world.

11.2 Entities

The first pattern to cover is the Entity pattern.
In this book the concept of an entity is the same as the concept of an aggregate in Domain-Driven Design literature.
An aggregate is an entity, including any of its child entities, and any of the value objects used inside of it.
In my experience the term “aggregate” leads to a lot of confusion so I decided to use the word “entity” in this book.
We have talked about entity design in Chapter 2: The domain model, and I’ve already mentioned several design rules for it there.
Still, I want this chapter to be a reference guide to the standard design patterns you’ll need in decoupled application development, so I’ll briefly summarize the rules here.
I’ll just declare the rules without defending them in detail.
You can always look up the reasoning in Eric Evans’ “Domain-Driven Design – Tackling complexity in the heart of software”, Addison-Wesley Professional (2003). A quick and accurate primer on the topic is Vaughn Vernon’s article series “Effective Aggregate Design”.

Entities are objects that preserve the state of your application.
They are the only type of objects in your application that have persistent state.
Most of the other objects should be designed to be immutable and stateless.
Being mutable, entities should not be passed to clients that don’t intend to change their state.
When a client

Truncated by Planet PHP, read more at the original (another 46211 bytes)

Byte-sized functional programming: Immutable variables are easier to understand

Larry
21 July 2020 – 7:30am