Obviously you can already access query parameters today already but it could be easier. Essentially what I want is a way for developers to easily configure what query parameters they expect and what values they expect. This is useful for several things like easier reading and validating of query parameters, self documenting API both for API docs for humans but also for machines.

He's asking for feedback and ideas from the community on a proposed solution that could make things more flexible. He also briefly mentions the route matching and how qurey parameters could cause them not to match:

For one I don't think that a mismatch on a route requirement of a query parameter cause the route to not match. However then it can quickly become confusing for the end user or it would require adding more and more syntax to handle all the different cases.

New in the PHP manual: a quickstart for the mysqlnd query cache plugin. PECL/mysqlnd_qc, the mysqlnd query cache plugin, is transparent and ease to use. But, how? Some pointers have been given in assorted presentations, here on my blog and in some, few examples from the manual. Fixed. You can now browse a quickstart to gain a quick overview.

The query cache plugin can replace the query caching MySQL does and can help with things like multiple storage options (memory, APC, Memcache, etc) and almost no changes to your application. There's also a method (mysqlnd_qc_get_query_trace_log) that comes with the plugin that gives you a "stack trace" of every query run through the MySQL interface.

In my previous article Introduction to MongoDB I discussed installing Mongo, its PHP extension, and how to perform simple insert and find operations. Of course there are many, many more features than what I mentioned so I wanted to write another article to show you some of them.

Other topics mentioned include queries on arrays of data and running queries with indexes to improve their performance. Code is also included for each example.

When running a PHP-based application with MySQL it is often quite interesting to see what actually happens on the database sever. Besides monitoring of the system load etc. it is often interesting to see what queries are actually executed and which of them are expensive. A part of MySQL Enterprise Monitor is the MySQL Query Analyzer which helps answering these questions.

This was handled via a proxy that sat between the database and app server and ran through the queries looking for improvements. This new plugin keeps it closer to PHP itself without having to hit against the proxy. You can see the result in these two screenshots from inside the Manager application. You also have the side benefit of getting a stack trace of it running through the app to help you identify the spots most needing improvement in the code too.

I've been working with the Basecamp API to plugin our IRC bot that we use for time tracking and I'm astounded to learn that escaping single and/or double quotes for XPath queries in PHP does not have a well documented, best practices solution. In fact, it seems as though this is not peculiar to PHP. I took a look around and found this excellent article by "Kushal": http://kushalm.com/the-perils-of-xpath-expressions-specifically-escaping-quotes.

He's put together his own (PHP) solution to the problem - running the entire XPath query through a filtering method that splits it up, replaces the quote characters and combines it back down to a single string.

Quite a while ago I looked at using the filter_var() function to validate URL's using the FILTER_VALIDATE_URL flag and someone pointed out recently that this function has not only changed since the initial release, but that a number of flags can be added to change the way that this function works.

He lists some of the other flags that are now available that can be used in conjunction with FILTER_VALIDATE_URL to get more fine-grained in your filtering - checks on things like a required scheme, hostname and query string. He includes some code with a set of URLs to run through some tests and output as a table with the pass/fail rank of each URL value. You can see the resulting output here.

Tweeting is what we do after publishing posts. To place some minimal text that jumps upon the Tweet on Twitter will be more great instead of using a tweet button. Its made possible to count the number of tweets using PHP only, however if you want to sizzle it up, then its your way.

They include code examples of how to connect to each of the services and make a request for a query string to their API using libraries provided by the service.

The new SDKs have not, as you can say, fallen far from the tree. While they are really great new and shiny, documentation on how to use them is still vague, missing or spread out in the internet in blogs like these, in posts from us users trying to share the information with other soon-to-be-suffering developers. So this is an example of this, i have been using these new resources and the new PHP-SDK and have ran into various walls, so I decided to start putting some of this on my blog, for 2 reasons: to spread the word, and to have notes for myself when I come back to this.

The post gives an example of using the "api" method provided by the PHP SDK from Facebook to push an array of parameters, one being the query, to the remote API for parsing. He includes the code for a simple (namespaced) helper to take in the query and return the API's return data set.

That's the situation. A web application with 4 heavy queries. Yes I know you can use a cache or things like that but imagine you must perform the four queries yes or yes. As I say before the four database queries are heavy ones. 2 seconds per one. Do it sequentially, that's means our script will use at least 8 seconds (without adding the extra PHP time). Eight seconds are a huge time in a page load. So here I will show up a technique to speed up our website using asynchronous calls.

Since PHP doesn't really support threading, he works around it by creating a separate script for each of the queries (obviously only practical for special cases) as a self-contained unit. Then the "master" script that needs the results of the queries calls each of them via asynchronous curl class (simply named "Fork") that sends off the requests and waits for each result to come back as a json result set.

Symfony 2 comes with native support to connect to MongoDB using the DoctrineMongoDBBundle. Getting started is quite simple and there is not much that needs to be configured, but the manual does not say how to enable query logging although it is already possible with Symfony PR3. Query logging allows you to debug queries sent to the DB server by writing them in a log file. It is very useful for cases when you issue a query and you are not getting the results you expected.

The key is to add a "logger_class" value into your Symfony configuration file pointing to the "DoctrineMongoDBLogger" tool. The queries will then show up in your normal log files. They include a sample line along with a brief explanation of the values inside.