Integrity Constraint Violation for 7100 update hook

Hi Ethan,
Thanks for telling us about this and for making a patch. It had just

--- scheduler.install
+++ scheduler.install

which is not formatted in the way Drupal Testing requires, so I have re-rolled it with:

diff --git a/scheduler.install b/scheduler.install
index fe526ad..e5a76ab 100644
--- a/scheduler.install
+++ b/scheduler.install

I understand your explanation but I have not replicated the problem or actually tested the patch yet.

Jonathan

I've tested this and it works fine. Easy to check, just reset the scheduler schema and re-run the updates. Previously it failed but now it does not.

Before I commit this I'd like to check with Pieter my co-maintainer who is now working on the 8.x version, as normally any changes would be made at 8.x first. But since this is a fix to a previous update function at 7.x which will not be usd in 8.x I am fairly sure this is OK.

This is a little bit less efficient since it will do a separate query for each role, but I don't think it would be too much trouble. The query is small so even on sites with many roles it should not take too much time.

Looking good to me. Thanks for the report and the fix!

Yes it is slightly less efficient but it avoids the main problem. I did try to re-write the original query inner join to also filter out the roles which already have the new permission. But it was not working right, and I spent too long on it anyway, so decided to use Ethan's code anyway.

I made the commit then tried to push the code, not realising that I was not at the latest version of 7.x. I triggered an automatic merge, which I have not used before, and was not intending. There is an extra commit now, http://cgit.drupalcode.org/scheduler/commit/?id=bb4dc2c but these changes were already done by you in #2122013: Separate tests that depend on the Date module so I'm a little confused as to what I have just done.

Jonathan

Don't worry about the automatic merge, it's harmless. If you want to avoid this to pop up in the history you can rebase your branch before you push:

$ git commit -m "Issue #12345 by xyz: Barred a foo."
$ git fetch
$ git rebase origin/7.x-1.x
$ git push

You can set this up automatically so that when you pull git will always do a rebase instead of a merge:

$ git config --global --bool pull.rebase true

If you then are in the situation that you accidentally committed on an outdated branch you can just pull:

$ git commit -m "Issue #12345 by xyz: Barred a foo."
$ git pull
$ git push

Remember that git pull is a shortcut for git fetch + git merge. That option changes the merge to a rebase globally so it will take effect for all git repositories on your machine.

The quickest way of making sure that your branch is clean and fully up to date with the remote repository is to fetch the new commits from the server and then reset your branch to be equal to the remote:

$ git fetch
$ git reset --hard origin/7.x-1.x

You can now commit and push in confidence.

Thanks Pieter for the hints. I did the commit, then the push failed telling me I was not up-to-date. So I did a git pull -v which invoked the merge. I did not do a rebase so I guess that option is not turned on. I've just used git config --list and there is nothing about pull.rebase so I presume it is not set and the default is False, so I have now set it to True. Cheers!