In this new post to his site Emir Karsiyakali shares a quick tip for the Laravel users out there to improve your logging output and make following requests easier.

Putting unique id to requests one of my silver bullet while designing RESTful APIs. It provides an extremely easy way to follow each request’s lifecycle while debugging. In this guide I’ll show you how you can add it to your log files on Laravel 5.6.

Under the hood, Laravel utilizes the Monolog library, which provides support for a variety of powerful log handlers. Laravel makes it a cinch to configure these handlers, allowing you to mix and match them to customize your application’s log handling.

He starts with adding the "tap" value to the logger configuration and pointing it to a newly created LocalLogger class. He shows the implementation of this logger class including a custom log formatter that will modify the log string to add the unique ID after the "datetime" value. He also includes some usage examples in your Laravel code, putting the Log::info line into a LogRequestResponse middleware to be executed on each request.

On the Laravel News site they've posted a tutorial showing you how to use the caching functionality for models based on the framework's Eloquent ORM layer. This caching makes for fewer queries to the database and can improve the overall performance of the application.

You’ve probably cached some model data in the controller before, but I am going to show you a Laravel model caching technique that’s a little more granular using Active Record models. This is a technique I originally learned about on RailsCasts.

Using a unique cache key on the model, you can cache properties and associations on your models that are automatically updated (and the cache invalidated) when the model (or associated model) is updated. A side benefit is that accessing the cached data is more portable than caching data in the controller, because it’s on the model instead of within a single controller method.

They start with an example of it in action, getting the count of comments on a news article based on a relationship. It then shows the use of the touch method to change the model's updated_at timestamp to the current time allowing you to more correctly detect when changes occur. It also includes a more automatic way of performing the same operation using the $touches class property on the model and the cacheKey method to create a unique key name for use in the caching system to reference the model contents.

On the Laravel News site there's a new post sharing some improvements with "unique" and "exists" validation that will be a part of the framework starting in version 5.3.18.

Validating requests in Laravel is simple with its ValidatesRequests trait that is automatically included through the BaseController.

It’s powerful and provides a lot of useful rules for common use cases. Two rules, exists() and unique(), are used to validate against data stored in your database. [...] The style of this is not the easiest to remember and it’s something you almost always have to consult the docs on.

Starting with Laravel v5.3.18 both of these rules have been simplified with an introduction of a new Rule class.

They include some code examples of using this new Rule class and how to use it right along side the current validation rule format for more complex validation needs. There's also a mention of an extra "bonus" that comes with the functionality: a conversion method for translating new rules back into strings.

In the latest post to the SitePoint PHP blog Vova Feldman shows you how to create an integer from a hash string that's both 64 bit and unique each time it's generated.

PHP provides the popular md5() hash function out of the box, which returns 32 a hex character string. It’s a great way to generate a fingerprint for any arbitrary length string. But what if you need to generate an integer fingerprint out of a URL?

He describes the real-world situation he was facing - a rating widget that needed a randomized integer based on the page using it - and the two "sub-challenges" that make it up: url canonization and the string to unique 64 bit problem. He tackles each problem and shares code snippets showing the process and how it can be put to use. He also includes some interesting metrics at the end of the post showing the level of hash collisions (hint, it's a very low number).

In a new post to his site Bob Majdak looks at using SQL in PHP and some of the challenges he's come across (some of them with his own tools). He talks about things line inline SQL, loading SQL by unique key or creating a "build object".

There is no right or wrong way, but no matter what there is no *pretty* way to do SQL inside of a PHP application. I have been having a personal debate with myself all week about how to make SQL statements nicer in an application without going to a huge DBAL package like Doctrine.

He looks at each idea and provides some of the pros and cons about each of them, noting that he hasn't quite decided on which is the best method. Some sample code is included to help clarify the points, showing the "find by unique key" version and how a more complex query might be created with the "builder object."

On PHPMaster.com there's a new tutorial posted showing you how to generate one-time use URLs that could be used for various things across an application, including things like account verification links.

A one-time URL is a specially crafted address that is valid for one use only. It’s usually provided to a user to gain privileged access to a file for a limited time or as part of a particular activity, such as user account validation. In this article I’ll show how to generate, implement, and expire one-time URLs.

Included in the post is the SQL to create a sample "pending_users" table that includes a "token" column for storing the generated hash. Code is also included for generating the hash and checking the incoming URL to see if it matches the requested user (and hasn't expired).

As a matter of general house keeping you could write a secondary script to keep expired tokens from accumulating in the database if a user never follows them. The script could be run periodically by an administrator, or preferably set up as a scheduled task or cron job and run automatically.

New on the ServerGrove blog today is a quick post talking about how you can enforce key constraints on a MongoDb with Doctrine in Symfony.

Of course you can define unique indexes to prevent duplicate values and there are a couple of different syntax options to do so, which are clearly defined in the official documentation. But defining and creating the indexes is not enough. You must specify when you want to enforce the constrain, this is due to the fact that the PHP driver needs to tell MongoDB to throw an error when a duplicate key is found.

The fix is as simple as adding a "safe" option to the "flush()" call on your database object. If you give it a value of "true", the ORM is smart enough to handle things on its own.

Havard Eide has a recent post to his blog that looks at a part of the Standard PHP Library (SPL) that can be used with objects to store them for later use - SplObjectStorage.

In this post I will look at SplObjectStorage: a container that allows to store objects uniquely without the need to compare them one by one.

He lets the code to most of the talking, showing how to do the standard operations for a data store - adding objects (both unique and the same), updating objects in the store, checking to see if an object is already added and removing an object from storage.

Brian Moon had a problem - one of his cron jobs was lasting for much longer (hours!) than it should have been. He tweaked, tested and debugged the script and finally came down to a call to in_array, something he comments on as being "quite slow".

See, this job is importing data from a huge XML file into MySQL. After it is done, we want to compare the data we just added/updated to the data in the table so we can deactivate any data we did not update. [...] We then compared the two arrays by looping one array and using in_array() to check if the value was in the second array. [...] So, that was running for hours with about 400k items. Our data did not contain the value as the key, but it could as the value was unique.

He method, replacing the in_array call that had to do a full array scan for each time through the loop with an isset/unset combo on the unique key, changed the execution time down from about 4 hours to 0.8 seconds.

On the Internet Super Hero blog, there's a post that looks at how PDO is implemented in PHP and wonders if the PDO::FETCH_UNIQUE constant is broken (as something to fix before even considering the move to PDO2).

I spent quite a lot of time comparing the different behaviours of the various drivers in the hope I could find out how PDO drivers are supposed to work. The PDO documentation and the specification do not cover each and every detail. PDO really needs some love...

He picks out the FETCH_UNIQUE constant as one that needs a little work and tries to track down exactly what it's doing. One issue he found was that it requires combination with other flags to make the unique part of it work correctly (like FETCH_OBJ or FETCH_COLUMN). He works through several examples, both ones that apply the unique call and others that don't, comparing the results.