Using Direct Database Queries to Quickly Update Data, Part 2 Using object-oriented principles to improve on class design for writing database queries to quickly update data.

This is the second, and final part, in a series about – as the title suggests – direct database queries. Specifically, it’s about changing post statuses (but it’s relevant to more than that).

Photo by Ross Findon on Unsplash

From the previous post:

This is yet another post that’s going to be an illustration of how to use $wpdb to¬†quickly update information based on metadata.

And the code provided in that post works but if you’re looking to make it more object-oriented, then there’s more work that can be done.

Before jumping into the actual post, though, it’s important to note that when it comes to object-oriented programming, there’s a lot of work that can go into the class design and creating levels of abstraction.

At some point, you have to draw the proverbial line between when you’re going to use interfaces, how granular your classes are going to be in terms of what they are abstracting, and the like.

And the purpose of this post is to help provide a better object-oriented design but it’s not an exercise is making this as optimal as possible. I do discuss topics like this in another series of posts.

But keep that in mind when reading through the code throughout the rest of the post.

Database Queries to Quickly Update Data, Part 2

Given where we left off, we have a single function doing the following things:

  1. retrieve all posts associated with a specific meta key,
  2. determine if we nee to exit early,
  3. update the post status of any existing posts.

The first thing to note is that a single function is too much, so it needs to be broken into several other functions. And since it’s object-oriented, we need to make sure that whatever a function is doing isn’t necessarily predicated on previous steps – that’s precisely what procedural programming is about.

Instead, we’ll use this opportunity to set up functions, so they operate on whatever data is passed to them regardless of how they got there.

Finally, it’s up to you, as the developer, to determine if you want to have a single class for doing this, more than one class, or have a set of related classes that inherit from a parent class.

Again, it’s all about how abstract you want to make the code.

For now, though, let’s move forward with breaking things up.

1. Grab the Post IDs with the Associated Meta Key

Just like in the first post, we want to make sure that we’re retrieving post IDs that are related to a specific meta key.

For the sake of making this function as flexible as possible, we’ll set it up to:

  • accept the meta key as a string,
  • return an array

The function will then look something like this:

In the first post, we broke this into three steps (which are also outlined above). Here, though, we can combine the second and third step into a single function.

2. Update the Post Status

As I mentioned, the one aspect of object-oriented programming is to make sure that the functions we’re using are agnostic as to how the data was generated that they are receiving.

Instead, they have a single algorithm to run to focus on the data that’s passed into the function. In this case, we want to take the set of results – which are post IDs – and update their post status so that it’s set to draft.

This means the function will accept an array but won’t return anything. Potentially, you could have it keep track of many posts it updated (or if it updated anything at all), but I’m focused on just refactoring the code we already have.

So that’s what we’re going to do. And the first thing is making sure there’s actual data with which to work And if so, then iterate through the list array of post IDs and change their post status:

You can see that it’s not much different from the work that’s been done in the first post, but it now raises a few questions.

3. Object-Oriented Considerations

When working with code like this:

  • Does it all belong in the same class or separate classes?
  • Should there be a base class and, if so, why or why not?
  • Should there be a single public function that’s invoked that calls these methods (and have them marked as private)?
  • Should we leave the functions public?

For this post, I’m going to do the following:

  • Expose each function as a public method. This is so that if there is data returned from the first method, you could potentially do something else with it.
  • Keep it contained in a single class. This way, we can instantiate a single class and then use it to do whatever work we need to do. If there were other methods, we’d use those same methods.
  • Start with the interface. I’m not going to bother writing an interface for the purposes of just showing an interface (I assume it’s easy enough to deduce given the functions we have right now), but I am going to take the class and show how we may invoke the functions “from the outside in.”

So I’m going to start with the last point and work backward. Here’s one way you can work with the code:

And then here’s what the entire class looks like:

Generally speaking, that’ll serve the same purposes as the first most but in a more object-oriented fashion.

That’s Not The Way

As I’ve tried to re-iterate several times through this post, this is not the definitive way to do this work. Instead, it’s one way that work can be done.

You can re-design, re-factor, or re-use this however you see fit. The purpose, though, is to show how to de-couple logic that we normally see as procedural into something that’s a bit less dependent on itself and leaves room for additional work.