These blog entries are tagged “mysql” after the MySQL database. However, they’re likely somewhat interchangeable with the content in the SQL tag and are often grouped together.
When you start your Docker containers, the database container might be “running” before MySQL is actually ready to accept connections. A healthcheck solves this by verifying the service inside the container is responsive.
I love using Eloquent’s sole() method in Laravel. It throws an exception if the result set is ever more than 1. It means you should only have a sole record. This is usually what I want. I’ve migrated away from firstOrFail() unless I legitimately want the first of a matching set.
But I just found another reason to love using the sole method - it helps add a layer of protection against SQL injection. Let’s find out how.
Docker provides the HEALTHCHECK instruction for Dockerfiles and Docker Compose files.
While not absolutely required, configuring these can make your IDE and environment more robust and verbose.
Here’s what I use with some common containers in Laravel projects.
When using the Docker MySQL Container, you can specify files in the /docker-entrypoint-initdb.d folder to be imported or ran when the container is brought up. These can be in the form of .sql, .sql.gz or .sh - and get ran after the database is up but before its accepting connections.
But what if you can’t seem to get these to run again? The fix is just so annoyingly simple.
This MySQL error isn’t as hard as you might think to solve. Let’s find out why it’s happening and what we can do to fix it.
I guess I should RTFM more often… but I didn’t remember (or know??) that MySQL truncate table causes an implicit commit.
By now, you’ve probably written many database migrations in Laravel. But, then something else happens. Perhaps your business model changed, your data attributes changed or you’re just refactoring to a stronger architecture. Doesn’t matter which, you’re going to need to convert and migrate some data.
The other day I was at a coffee shop and I looked around at all the Mac’s open. It used to be that you’d see people writing manuscripts at coffee houses. Surprisingly, this place held a lot of programmers. I suddenly thought of something interesting:
Measurement is important. Metrics, while not sexy, are concrete to a good business strategy. When you bring a problem to your superiors, they’re going to want to know what is your measurement, what metrics did you use to determine this is a problem. With tasks I’ve given developers, I’ve always said “show me the metrics that your fix is better” versus just looking at the code.
Here is an interesting proof of concept that the ‘rows’ column of the explain output is actually an estimate, and not the real amount. I KNEW it to be true, but somehow I didn’t feel like it was right. I always thought “the closer the rows # gets to the exact amount of retrieved data, the better. Exact is what you strive for.” Turns out, that’s not true. The closer the number, the better, but its still just an estimation. Sometimes its estimated accurately, other times its not. See this example:
I’m no sys admin, so I can’t be sure, but I’ve seen lots of issues with using things like MySQL Proxy to fully separate the write and read queries in an application. Maybe it works, I don’t know… but I do know that if I can separate the connections in my code, that saves my Admin time… it doesn’t appear to give that much of a hit to performance either! Do keep in mind that this is only working at the table level in Zend Framework. If you use their database system, this should do the trick. If you do a lot of getting the adapter yourself, this won’t help you at all!
The last time I created a char(1) for a flag field, I remembered the MySQL BIT field - so I did a bit of investigation. I thought, well if I can make a bit field of one bit that is either 0/1, I can save data space in my db.
So the other night I was thinking about using xdebug on my PHP code. I then totally had a brain explosion: I’m always forgetting to profile my MySQL queries. explain is a great command for this. However, as the lazy programmer I am, I don’t know if I’m always going to do this on all of my queries. In an attempt to save myself time, I started brainstorming an idea.
As you probably know by now, I’m a huge fan of Eclipse PDT. Well, I wanted to stop using MySQL GUI tools for a bit and explore Eclipse tools.
Every once in a while, I forget about the built in awesomeness of MySQL. Today, I was looking at a unix timestamp from PHP in one of the fields and was wondering what that date was. Derr, use from_unixtime function!
There are a few quick ways to monitor MySQL performance. This isn’t much of an in-depth reference, just a quick reminder. Let’s look:
After looking at the Windows model for controlling file access, I realized I could also do that for user authorization control.
I’ve been wondering if I should be concerned about re-preparing a prepared statement when using PDO. Right now, I use code like this when preparing a statement: