Re: sqitch problem

[David E. Wheeler]

Hi Sqitch Fans,

Posting my reply to Rolf to the list in case others run into this kind of issue in the future.

On Aug 7, 2013, at 3:47 PM, Rolf Schaufelberger <r...@plusw.de> wrote:

> Hello David,
>
> sometimes we get an error message like this:
>
> $ sqitch deploy
> Cannot find 78892d84835f2eb5ee91e0301b15996d1f02f2c5 in the plan
>
> now, when I look in changes I find:
>
> change_id | change | project | note | committed_at | committer_name | committer_email | planned_at | planner_name | planner_email
> ------------------------------------------+-------------+----------+-----------------------+-------------------------------+----------------+-----------------+------------------------+--------------+---------------
> 78892d84835f2eb5ee91e0301b15996d1f02f2c5 | lbs_reorder | iprinter | Campign f lbs umbauen | 2013-07-10 08:53:56.330321+02 | Rolf | r...@plusw.de | 2013-07-09 11:59:23+02 | Rolf | r...@plusw.de
>
> and my sqitch.plan looks like that:
>
> %syntax-version=1.0.0-b2
> %project=iprinter
> %uri=http://www.i-printer.de/
>
> seo_titles_and_label 2013-06-07T14:14:20Z Tim Schwarz <ts@wsmk> # Change lexicon key title and add label for productdescription
> ….
> camp_cat_parent 2013-07-09T09:58:22Z Rolf <r...@plusw.de># Spalte parent in campaign_categorie dazu
> lbs_reorder [camp_cat_parent] 2013-07-09T09:59:23Z Rolf <r...@plusw.de> # Campign f lbs umbauen
> jdlbs_proto_paysystem 2013-08-05T13:27:07Z Patrick Goldmann <p...@plusw.de> # add proto_paysystem company_param for jdlbs
> ….
>
> Any hint what is going wrong here and how we can fix it?

Did you happen to edit the lbs_reorder change in the plan, or any of the changes that come before it? If so, its SHA1 will change. Curious to see the text used to generate the SHA? Run this command:

sqitch show change lbs_reorder

The output will be something like this:

project iprinter
uri http://www.i-printer.de/
change lbs_reorder
parent 925111084c4f4f55d7a0fcf312bc915bd330d999
planner Rolf <r...@plusw.de>
date 2013-07-09T09:59:23Z
requires
+ camp_cat_parent

Campign f lbs umbauen

So if you have changed the date, planner name or email, prerequisites, or note, the SHA1 will change. Also note the "parent" line: this means that if the SHA1 of the parent (which in your case is camp_cat_parent) or any of the previous changes have been modified in the plan -- or reordered them -- then all subsequent SHA1s will change.

There are two ways to deal with this:

1. If it is a production database you are deploying to, you need to revert whatever changes you have made. If you have deployed up to some change to production, Sqitch expects that they will never change. So you should not change them in the plan, either. This is to be as conservative as possible with production systems, to prevent inadvertently applying changes that are unaware of each other.

2. If it is not a production system, you can revert the changes. The revert command falls back on looking up changes by name if it does not find them by SHA1. This makes it easier to make changes while doing development. For example, if what happened is that you changed the note in the camp_cat_parent change, then you can revert and deploy in one command, rebase, like so:

sqitch rebase --onto camp_cat_parent^

That will revert everything through camp_cat_parent, then reapply camp_cat_parent and continue through the plan in order.

HTH,

David

[Rolf Schaufelberger]

>> sometimes we get an error message like this:
>>
>> $ sqitch deploy
>> Cannot find 78892d84835f2eb5ee91e0301b15996d1f02f2c5 in the plan
>>
>> now, when I look in changes I find:
>>
>> change_id | change | project | note | committed_at | committer_name | committer_email | planned_at | planner_name | planner_email
>> ------------------------------------------+-------------+----------+-----------------------+-------------------------------+----------------+-----------------+------------------------+--------------+---------------
>> 78892d84835f2eb5ee91e0301b15996d1f02f2c5 | lbs_reorder | iprinter | Campign f lbs umbauen | 2013-07-10 08:53:56.330321+02 | Rolf | r...@plusw.de | 2013-07-09 11:59:23+02 | Rolf | r...@plusw.de
>>
>> and my sqitch.plan looks like that:
>>
>> %syntax-version=1.0.0-b2
>> %project=iprinter
>> %uri=http://www.i-printer.de/
>>
>> seo_titles_and_label 2013-06-07T14:14:20Z Tim Schwarz <ts@wsmk> # Change lexicon key title and add label for productdescription
>> ….
>> camp_cat_parent 2013-07-09T09:58:22Z Rolf <r...@plusw.de># Spalte parent in campaign_categorie dazu
>> lbs_reorder [camp_cat_parent] 2013-07-09T09:59:23Z Rolf <r...@plusw.de> # Campign f lbs umbauen
>> jdlbs_proto_paysystem 2013-08-05T13:27:07Z Patrick Goldmann <p...@plusw.de> # add proto_paysystem company_param for jdlbs
>> ….
>>
>> Any hint what is going wrong here and how we can fix it?
>
> Did you happen to edit the lbs_reorder change in the plan, or any of the changes that come before it? If so, its SHA1 will change. Curious to see the text used to generate the SHA? Run this command:
>

Yes, that was the the problem. I had a bug in my sql a an colleague fixed that.
So what is the correct way to avoid this problem?

the sequence of actions was
User A, database from user A
sqitch add xyz
sqitch deploy
git commit … , git push

# Deploy worked on database from user A

user B, database from user B:
git pull
sqitch deploy
-> user B gets an error, fixes sql in deploy/xyz.sql
sqitch deploy
git commit … , git push

User A:
git pull
sqitch deploy
-> error as described above

> sqitch show change lbs_reorder
>
> The output will be something like this:
>
> project iprinter
> uri http://www.i-printer.de/
> change lbs_reorder
> parent 925111084c4f4f55d7a0fcf312bc915bd330d999
> planner Rolf <r...@plusw.de>
> date 2013-07-09T09:59:23Z
> requires
> + camp_cat_parent
>
> Campign f lbs umbauen
>
> So if you have changed the date, planner name or email, prerequisites, or note, the SHA1 will change. Also note the "parent" line: this means that if the SHA1 of the parent (which in your case is camp_cat_parent) or any of the previous changes have been modified in the plan -- or reordered them -- then all subsequent SHA1s will change.
>
> There are two ways to deal with this:
>
> 1. If it is a production database you are deploying to, you need to revert whatever changes you have made. If you have deployed up to some change to production, Sqitch expects that they will never change. So you should not change them in the plan, either. This is to be as conservative as possible with production systems, to prevent inadvertently applying changes that are unaware of each other.
>
> 2. If it is not a production system, you can revert the changes. The revert command falls back on looking up changes by name if it does not find them by SHA1. This makes it easier to make changes while doing development. For example, if what happened is that you changed the note in the camp_cat_parent change, then you can revert and deploy in one command, rebase, like so:
>
> sqitch rebase --onto camp_cat_parent^
>
> That will revert everything through camp_cat_parent, then reapply camp_cat_parent and continue through the plan in order.
>

>> And , now to something completely different:
>> I know you are very familiar with postgres extensions. I've mailed a question to stackoverflow , maybe you can help me with that too:
>>
>> http://stackoverflow.com/questions/18098913/postgresql-create-extension-fails
>
> Curious. I do not get that error. I added a question to the SO post.
>
> HTH,
>
> David
>
>
Rolf Schaufelberger

[David E. Wheeler]

On Aug 7, 2013, at 11:15 PM, Rolf Schaufelberger <r...@plusw.de> wrote:

> Yes, that was the the problem. I had a bug in my sql a an colleague fixed that.
> So what is the correct way to avoid this problem?
>
> the sequence of actions was
> User A, database from user A
> sqitch add xyz
> sqitch deploy
> git commit … , git push
>
> # Deploy worked on database from user A
>
> user B, database from user B:
> git pull
> sqitch deploy
> -> user B gets an error, fixes sql in deploy/xyz.sql
> sqitch deploy
> git commit … , git push
>
> User A:
> git pull
> sqitch deploy
> -> error as described above

It should not affect anything if only the deploy script itself was edited. Only if User B changed the plan by adding or removing dependencies, changing the order of things, or changed the note.

Best,

David