GizmoLA.com

Certainly the most convenient way to develop a Symfony 5.x app is to use the symfony server. Eventually however, you may have to deploy the application. For a number of years nginx with php-fpm was the preference for many sysadmins seeking to wring the maximum performance out of a webserver that also has to run php scripts, but there are now simple ways of configuring apache to use php-fpm while achieving comparable performance to nginx.

For example a vhost setting like this one is possible:



Continue reading "Symfony 5.2 and Apache 2.4"

So you have a private Bitbucket Repo and you want to utilize it in your project composer.json. You may find that when you run the composer install you get an error pulling your private Bitbucket repo with messages about Oauth failure that may include "Invalid OAuth consumer provided"

Continue reading "Composer install of Private Bitbucket VCS "aka" 'Invalid OAuth consumer provided'"

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! "