-
Notifications
You must be signed in to change notification settings - Fork 46
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
Support Schedule #62
Conversation
This defines the latest database version Cavalcade uses.
There was a problem hiding this 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.)
inc/class-command.php
Outdated
* Upgrade to the latest database schema. | ||
*/ | ||
public function upgrade( ) { | ||
require_once __DIR__ . '/upgrade/namespace.php'; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In a6736c1
inc/class-command.php
Outdated
require_once __DIR__ . '/upgrade/namespace.php'; | ||
|
||
if ( Upgrade\upgrade_database() ) { | ||
\WP_CLI::success( 'Database version upgraded.' ); |
There was a problem hiding this comment.
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 \
There was a problem hiding this comment.
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.
inc/class-command.php
Outdated
return; | ||
} | ||
|
||
\WP_CLI::error( 'Databse upgrade not required.' ); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in 38c423c
Removes a typo and always returns them as successful to avoid failures that can’t be preemeted.
Needs some additional logic for rescheduling tasks. Currently, rescheduling an event with the same |
inc/class-command.php
Outdated
* Upgrade to the latest database schema. | ||
*/ | ||
public function upgrade( ) { | ||
if ( Upgrade\upgrade_database() ) { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
The Job instance always has a schedule set.
@rmccue I reckon this is ready for another look:
The comment above was a misunderstanding on your author's behalf... |
There was a problem hiding this 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 ) { |
There was a problem hiding this comment.
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.
inc/upgrade/namespace.php
Outdated
|
||
$query = "ALTER TABLE `{$wpdb->base_prefix}cavalcade_jobs` | ||
ADD `schedule` varchar(255) DEFAULT NULL | ||
AFTER `interval`"; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
Adds support for the WP Cron API's named schedules.
See #29