Phil Sturgeon as a new post to his site today talking about the importance of serialized API output and why it's important to think about what to share and how they're shared.

One section that seems to get a lot of feedback and questions is when I talk about serialization, which I refer to as “adding a presentation layer to your data”. [...] To PHP developers, they often consider serialization to be using the serialize() function. Yes, this is one form of serialization, but it’s not the only one. Another common serialization approach is of course to use the json_encode() function. [...] Excuse the drastically simplified chunk of code here, but the point is we’re taking a model (probably using an ORM) and returning the result directly. This seems fairly innocent, but leads to a range of problems.

He suggests that, when thinking about the data coming out of your API, you have to assume that every possible value could be shared if models are output directly. He gives the example of user passwords which, obviously, don't need to be shared at all. He includes an example of formatting the output with the Fractal library and why using something like that is important. He covers some of the topics to think about including attribute data types, renaming fields to make them more clear, the ability to pull from multiple data stores and the ability to version serializers. He ends the post with links to a few different serialization formats and some solutions (not just PHP ones) that can be used for the sort of handling he recommends.

In his latest post Derick Rethans shares his answer to a question he was asked at a recent PHP conference regarding the escaping of input before use in a MongoDB query.

At last weekend's PHP Benelux I gave a tutorial titled "From SQL to NoSQL". Large parts of the tutorial covered using MongoDB—how to use it from PHP, schema design, etc. I ran a little short of time, and since then I've been getting some questions. One of them being: "Should I escape my input, and if so, how?". Instead of trying to cram my answer in 140 characters on Twitter, I thought it'd be wise to reply with this blog post. The short answer is: yes, you do need to escape.

He uses the rest of the post to get into the longer answer, a bit more detail about why you should escape and what kinds of things can be done. He points out that, because of how MongoDB queries are created, SQL injection is much more difficult. He does remind you that superglobals can also be used to send arrays too which could lead to unexpected data input. He gives an example of how this would work and why it would be a problem.

So although MongoDB's query language does not require you to build strings, and hence "escape" input, it is required that you either make sure that the data is of the correct data type.

In this recent blog post nikic takes an in-depth look at how large PHP arrays really are - how memory is used in the creation and management of these handy PHP variable types.

In this post I want to investigate the memory usage of PHP arrays (and values in general) using the following script as an example, which creates 100000 unique integer array elements and measures the resulting memory usage. [...] How much would you expect it to be? [...] Now try and run the above code. You can do it online if you want. This gives me 14649024 bytes. Yes, you heard right, that’s 13.97 MB - eightteen times more than we estimated.

He goes into the details of PHP's memory management and breaks it down into the different totals (for 64 bit and 32 bit OSes) and details on each - zvalue_value, zvalue, cycles collector, Zend MM allocator and the buckets used to isolate one array (hash table/dictionary) from another.

What does this tell us? PHP ain't C. That's all this should tell us. You can’t expect that a super dynamic language like PHP has the same highly efficient memory usage that C has. You just can't.

If you're new to the PHP language and are looking for the full scoop on working with the string datatype, look no further than this new post from Mrinmoy Ghoshal. It's an excellent (and quite complete) resource for just about everything involving strings in PHP.

A string is series of characters, where a character is the same as a byte. This means that PHP only supports a 256-character set, and hence does not offer native Unicode support. See details of the string type.

The tutorial is broken up into different sections for easier consumption:

• Single quoted
• Double quoted
• Heredoc
• Nowdoc
• Variable parsing
• String access and modification by character
• Useful functions and operators
• Converting to string
• String conversion to numbers
• Details of the String Type

Alberto Viana has a new post to his blog about using Oracle ZML Types with a Zend Framework application. He created a custom adapter to create the type and handle the binding/execution on an new OCI8 connection.

So few days ago I needed to insert Oracle XMLtype with Zend Framework. I used oracle adapter to wrote it in Zend Framework. I was looking for and I found on Chris Jones Blog.

His table has a column defined as an XMLType, a special data type specifically for working with XML datasets directly in the database. His adapter includes a bit of sample XML and the code needed to bind the data as a CLOB and, using the writeTemporary function.

On the PHPMaster.com site today, there's a good introduction to a basic data type in PHP - working with arrays. This tutorial is a low level look at what arrays are and how to work with them (briefly).

Tables organize data in such a way that we can easily find correlations or perform straightforward computations. A array is essentially a way to organize data in a table-like manner. The name “array” comes from the same Latin roots as the word “arrangement.”

If you're anything other than completely new to the language, this post won't help you much. If you're new to programming, though, learning about arrays in PHP is key to your budding development skills. For more in-depth looks at using arrays, checkout these results.

In this new post to his blog, Rob Allen has posted notes on some of his experience in working with blobs with SQL Server using UTF-8.

This turned out to be easy enough: Use ntext, nvarchar types in the database and add resources.db.params.driver_options.CharacterSet = "UTF-8" to your application.ini

He also includes some code to fix a problem he spotted with storing binary data into a varbinary field giving him an error about string translation. The fix came in the way of replacing the direct file_get_contents assignment to a variable over to a binding method that specified the data type as well.

In this new post Jeremy Johnstone looks at creating a class to add that's missing from the basic datatype set of the language - enums.

I stumbled across a blog post on how to implement Enums in PHP via userland code written by Jonathan Hohle. I liked the concept he had, but the implementation was a bit unappealing because it used eval() among other more minor issues. You shouldn't need to generate Enums at runtime, so I took that as a challenge to find a way to do it at compile time, thus making the code much more efficient.

His enums would support type hinting and would, ideally, be iterable. He gives the code he's worked up - a base class, another than extends it to make a basic enum structure and some handy changes to support comparisons. A few more changes (and a few other extended classes later) he has some pretty well functioning enums that can even bee iterated through.

After struggling with it for a good while, Maggie Nelson finally figured out the answer to her problems with Oracle, PDO and CLOBs - they're just not supported.

LOB support was added to PDO_OCI in PHP 5.1. This is really cool, however, it appears that the LOB support really means BLOB support. After much investigation and self-doubt (e.g. "what if we're using streams incorrectly?"), we found out that PDO_OCI does not currently support CLOBs (BLOBs only!).

The bug's already been documented and remains open, but Maggie encourages all of the Oracle developers out there with the fact that Chris Jones (of Oracle) knows about the issue and plans to correct it in the next release of the extension.

After struggling with it for a good while, Maggie Nelson finally figured out the answer to her problems with Oracle, PDO and CLOBs - they're just not supported.

LOB support was added to PDO_OCI in PHP 5.1. This is really cool, however, it appears that the LOB support really means BLOB support. After much investigation and self-doubt (e.g. "what if we're using streams incorrectly?"), we found out that PDO_OCI does not currently support CLOBs (BLOBs only!).

The bug's already been documented and remains open, but Maggie encourages all of the Oracle developers out there with the fact that Chris Jones (of Oracle) knows about the issue and plans to correct it in the next release of the extension.