The Laravel News site has a quick post today with a helpful hint for those trying to track down exactly what queries their Laravel application is performing on database calls. In this post they show two ways to get this information - one using the Debugbar and the other with a quick script.

When you are building an application and utilizing Eloquent it’s very easy to hit the N+1 problem. This is where you select a model and then later use lazy loading to fetch child records.

They give an example of selecting a user, grabbing it's list of "posts" and then looping through them causing queries to fire for each post individually. A fix for it is using the "with" method to pre-load them but determining this could be tricky. Enter their two solutions: the Laravel Debugbar package and this quick script shared by magkopian that listens for a "kernel.handled" event and outputs the results of the "getQueryLog" method with the Laravel "dd" helper.

Brian Swan has a new post to his MSDN blog today about the release of the latest version (3.0 beta) of the SQL Server drivers for PHP. This new release includes three improvements - buffered queries, support for LocalDB and support for high availability/disaster recovery.

A Community Technology Preview (a beta release) of v3.0 of the SQL Server Drivers for PHP was released today (see the announcement on the team blog). You can download it here: Download v3.0 of the SQL Server Drivers for PHP. [...] It’s important to note that the latter two features are dependent on the next version of SQL Server (code named "Denali"). A preview of Denali can be downloaded for free here (see notes later in this article about the installation process): Download SQL Server Denali CTP 3.

He gives brief summaries (some with example code) of what these three new features have to offer those using SQL Server in their applications. The "buffered queries" allows you to bring your entire result set into memory, making it simpler to interact with as rows/columns. The LocalDB support gives developers a quick way to have a database without the hassle of a server - just connect right to the SQL Server database file. The high availability feature has been included for a while but has a new name in the upcoming release - SQL Server Always On.

Following up from the previous article on the Metapundit.net blog, there's part two of the "Code Smells" series - a look at bad things to do in your code (to make it "smell").

This (and any subsequent posts in the series) will be more limited in scope - a single bad example and a corresponding solution.

This time, the spotlight is on parameterised queries - inserting the variables directly into a SQL statement string versus filtering them or inserting them via a custom query() function. He points out that there's no need to create this kind of filtering/database handling class on your own, though - there's already been one created by the fine folks of PEAR (using the autoExecute function

Following up from the previous article on the Metapundit.net blog, there's part two of the "Code Smells" series - a look at bad things to do in your code (to make it "smell").

This (and any subsequent posts in the series) will be more limited in scope - a single bad example and a corresponding solution.

This time, the spotlight is on parameterised queries - inserting the variables directly into a SQL statement string versus filtering them or inserting them via a custom query() function. He points out that there's no need to create this kind of filtering/database handling class on your own, though - there's already been one created by the fine folks of PEAR (using the autoExecute function