GizmoLA.com

MongoDB currently does not offer the equivalent of a SQL Update statement when you want to change the value of a string to something that is based on the current value. In my case I needed to find spaces and change them to underscores -- something done easily in php with str_replace(), and in MySQL with REPLACE.

If you had a table named foo with a column named "mystr" you could do this sort of update like this:



MongoDB does have collection.update() that works with a series of "modifier" operations, but none of them are useful for doing modifications to the current value of a document field when that field is a string.

MongoDB does however support javascript, and the javascript replace() function implements a regular expression search and replace. I was able to accomplish the update using the forEach() method to process the resulting documents one at a time. While not as efficient as having mongo do this internally with a specially built update modifier, at least this method only needs to operate on documents that are known to require modifications, and could be run in the mongo interactive client easily.

Again, assuming the collection is named "foo" and the document field is named "mystr"



An existing patch promises to add a new update() modifier but until such a time as it exists, this approach can be used when you need to update strings in a collection, referencing the existing values in the transformation.

One of the first things people learn about using subversion is how to do a "checkout" using svn co. The svn checkout command pulls files from the subversion repository into your "sandbox" and in so doing creates what subversion calls a "working copy". A working copy includes a .svn directory in every subdirectory of the working copy, which is chock full of directories and files that svn uses to determine what you're doing in your sandbox.

A "working copy" is designed to be just that -- a copy of the source tree built with the assumption that you will be making changes and committing them back to subversion. But what do you do if you want the files, but you don't need or want a sandbox?

Continue reading "Get files from subversion without creating a sandbox using svn export" »

The MySQL timestamp is an oddity, being both a mySQL "Data Type" as well as a type of specialty column that provides a built in default. It doesn't help matters, that the timestamp was changed significantly around mysql version 4.1.

The Old TIMESTAMP

In older mysql versions, the TIMESTAMP was not in the same format as a DateTime column, and you could also set up truncation by defining the TIMESTAMP to have a fixed size. For example, you could define a TIMESTAMP column to be a TIMESTAMP(4) which would then only store the 4 digit Year portion of a DateTime value. I won't go into much detail on the pre version 4.1 TIMESTAMP, however, if you're stuck with an older version of MySQL I recommend you read the manual carefully before you attempt to use any of the information here. I'm going to concentrate on the current TIMESTAMP.

TIMESTAMP Properties

At its most fundamental, the TIMESTAMP is really nothing more than a Unix TimeStamp, which is to say, that internally it is stored as an integer value of seconds. Where a MySQL DATETIME column can be used to store any date and time from Jan 1, 1000 to 12/31/9999, the TIMESTAMP is limited in the same ways that the Unix timestamp is currently limited -- it can only store values from Jan 1, 1970 to Jan 9, 2038.

Those familiar with Unix design, will recognize the Jan 9, 2038 date as being the next big "Y2K" computing panic, and if you're young enough, you may realize a large payday in your future, selling remediation services to companies in roughly another 28 years. The folks at http://www.y2038.com/ are already estimating this to be as much as a 10 trillion dollar jackpot, although no doubt by that time most of the coding will be done by the Morlocks from their underground cave cities. Outsourcing of IT to Morlocks will be a major industry trend by the year 2020, mark my words.

Continue reading "Too much information about the MySQL TIMESTAMP" »

You can't add to Null

Here's something about mysql create table definitions that can easily catch you if you aren't careful. Consider this table definition:





What the user wanted was a simple table to keep track of user submitted screen shots. Of course the real table had a submission date, and name column but I've omitted those in order to focus on what can happen when you allow a numeric column to have NULL values.

In the application in question, when a user votes for the screen shot they like, the system should "count" the vote, by increasing the values in the "votes" column by one. Initially the developer working on this application was trying to read the value from the database, and in a PHP web script, they would increment this value and take the result and set "votes" to be equal to it in an UPDATE statement. I explained that this could cause lost votes, because if two or more users were voting at nearly the same time, each would overwrite the value of the "vote" column. In fact there are scenarios far worse than that --- a user with a cached page could vote and set the vote count back days or weeks. I didn't bother to mention the possibility that someone might recognize what was going on in the web form, and start tampering with it, since it was plainly evident that the form was passing the current number of votes.

One of the many benefits of using a relational database is built in concurrency. In an UPDATE statement, you can add to the value of the column without having to know what its original value is, just as computer languages allow assignment to a variable that references the variable's current value (ie. $a = $a + 1, $a++).



All that's needed is to have the serverside language provide a value for a particular "id" and the votes will be tallied and updated correctly. Even more importantly, mysql will serialize the updates, insuring that no votes are lost.

However, given the original Mysql CREATE TABLE statement , what will happen if our code embeds the UPDATE statement provided?

Continue reading "Mysql Update: Null + 1 is Null! " »

Here are the slides for the presentation on subversion I gave at the September 2008 LampSIG meeting. I hope some may find them useful, however they were meant only to provide a skeleton for the talk, and aren't a complete tutorial by any means. The following links to other sites were mentioned in the talk:

The Red bean book, aka Subversion manual
The svnmerge python script
Subversion tips Article
Subversion Cheat Card

A few years ago I published a 3 part LAMP tutorial series entitled LAMP, MySQL/PHP Database Driven Websites on the well known php community website PHPFreaks.com. This series dealt with a slew of practical issues including how a LAMP server works, relational database design using MySQL, many to many tables, SQL inner and outer joins, practical PHP debugging, php documentation tools, basic PHP classes, css, interactive javascript & DHTML with a chooser widget, php HEREDOC and php basics like how to process forms and utilize GET and POST methods.

The series was fairly successful, (a 4.5 of 5 after hundreds of ratings), many pages of comments and questions, and page views to the 100k's+ although PHPFreaks auditing system was turned off at some point and stopped recording views.

Unfortunately, some years ago PHPFreaks.com suffered some fairly catastrophic issues with its publishing system. There were also some bugs, and the site was exploited with some XSS, and the admins simply decommissioned the majority of the site. My series was part of what disappeared. At that point, a couple of college Computer Science courses on web development had taken the series and integrated it into their curriculum, and the professor of one of these courses had converted it into a Word document, which I was able to download and convert to pdf.

I plan to write a compatible publishing addon for gizmola.com so that I can take the original markup and republish it here, but in the meantime, here is the series in pdf format. The conversion utility they used stripped out the original markup, and page breaks are gone, but the text, source code, and illustrations are all still there.

I also offer all the source code for parts 2 & 3 of the series. I'm not sure what happened to the source for part 1, however, it is all included inline in the tutorial. The LAMP, MySQL/PHP Database Driven Websites series is now available in pdf format. Click here.