Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Schedule #62

Merged
merged 20 commits into from
Oct 23, 2018
Merged

Support Schedule #62

merged 20 commits into from
Oct 23, 2018

Conversation

peterwilsoncc
Copy link
Contributor

Adds support for the WP Cron API's named schedules.

See #29

Copy link
Member

@rmccue rmccue left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks on-track to me, just some small nits. (Also, no need to prefix your commits with an issue number.)

* Upgrade to the latest database schema.
*/
public function upgrade( ) {
require_once __DIR__ . '/upgrade/namespace.php';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be loaded in the main plugin file, not just-in-time.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In a6736c1

require_once __DIR__ . '/upgrade/namespace.php';

if ( Upgrade\upgrade_database() ) {
\WP_CLI::success( 'Database version upgraded.' );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WP_CLI is already use'd, so doesn't need the \

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In ddb0f12, I've left the existing instances in the file to avoid touching extra lines.

return;
}

\WP_CLI::error( 'Databse upgrade not required.' );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Database. Also, IMO this should be ::success instead, unless there's a good reason to fail. Given there's no needs-upgrade command, you otherwise can't know beforehand if this will fail or not.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spellng corrected, switched to success in 9bf2bdb

@@ -12,6 +12,7 @@ class Job {
public $start;
public $nextrun;
public $interval;
public $schedule;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably default to __fake_schedule or whatever we called it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 38c423c

@peterwilsoncc
Copy link
Contributor Author

Needs some additional logic for rescheduling tasks.

Currently, rescheduling an event with the same schedule results in a new entry in the jobs table as the calls to array_diff() see them as different.

* Upgrade to the latest database schema.
*/
public function upgrade( ) {
if ( Upgrade\upgrade_database() ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this be run automatically, or are we thinking we'll need to run this on every site manually?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking to run in manually on every site, in part to avoid any performance issues around running the ALTER query on large tables. I'm not sure if this is a real or imagined issue.

As it currently stands, there is a bug around rescheduling that I need to figure out. Depending on the approach, I may need to modify each row as part of the upgrade routine.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After some testing this morning, I did need to add a data upgrade routine in bc50540

@peterwilsoncc
Copy link
Contributor Author

peterwilsoncc commented Aug 25, 2018

@rmccue I reckon this is ready for another look:

  • Still requires upgrade routine
  • it adds best guess data on upgrade
  • version one database schemas include best guess schedule name
  • connector uses fallback generated in the Job object

Needs some additional logic for rescheduling tasks.

The comment above was a misunderstanding on your author's behalf...

@peterwilsoncc
Copy link
Contributor Author

@joehoyle Requesting a review from you on @rmccue's suggestion it get reviewed by the servers team.

Copy link
Member

@joehoyle joehoyle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me. As I mentioned before, I think the upgrade path if a bit of a faff, but like you mentioned I'm not sure if there's much way around that. I think in our case we'll just need to have a ticket to manually run it across everything. At the minimum I have no issue with this PR going in as-is. Thanks for all the work!


$schedules = Cavalcade\get_schedules_by_interval();

foreach ( $schedules as $interval => $name ) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've tested this PR on my site without populating the data and it looks like we can get away without doing so due to the fallback mechanism in the Job class.


$query = "ALTER TABLE `{$wpdb->base_prefix}cavalcade_jobs`
ADD `schedule` varchar(255) DEFAULT NULL
AFTER `interval`";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think, although I am uncertain, that adding new columns into the middle of the table causes horrific performance problems. IIRC, it has to create a temporary table, copy all records, then replace the real one, locking the table the whole time.

Trying to verify that now, but given we don't really care about the order, should we just add this to the end? IIRC, the performance is much better with that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've moved it to the end in 01ab379.

Placing the new column in the middle of the table may lead to a performance hit as the table is upgraded.
Copy link
Member

@rmccue rmccue left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's ship it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants