Include parent ID in text hashed for change IDs #56

Closed
theory opened this Issue Nov 12, 2012 · 5 comments

Comments

Projects
None yet
1 participant
Owner

theory commented Nov 12, 2012

Rather than relying on the most recently-applied change, consider storing the current change name (and ID) in the projects table. This will remove ambiguity. Also consider modifying the ID stored in the database to depend on parents as part of how it is created, so that if order is changed, we can detect that and refuse to deploy. Revert would still have to work, though.

theory was assigned Nov 12, 2012

Owner

theory commented Nov 21, 2012

Added the parent ID to the hashed text in af71fe6, and added it to the ChangeList index in 0555acd. Still to do to complete handling of old IDs:

  • Update Engine to fallback on old IDs
  • When it finds by an old ID, it should update the change and tag IDs in the database.
  • It should also determine the actual final ID, since it may be after the ID listed, since the deploy order could have changed since 696334a.
  • Make sure that @LAST^ uses OFFSET 1 LIMIT 1.
  • Make sure that revert uses the list of deployed changes, rather than the list of changes in the plan.
  • Sanity check it with some stuff built with the previous version of Sqitch.

I've decided not to add the latest change ID to projects, since one will often want, e.g., @LAST^^, so it will always need to query the changes table, anyway.

@theory theory added a commit that referenced this issue Nov 21, 2012

@theory theory Add code to update IDs in pg.pm.
Along with tests. Ref #56. In passing, also:

* Emit a message from the parent _update_ids() notifying the user what we're
  doing.
* Add an `ON UPDATE CASCADE` expression to an FK that was missing it.
* Correct some pastos in the Plan docs.
* Set the plan and remove some diagnostics in `t/engine.t`.
10f3c29

@theory theory added a commit that referenced this issue Nov 21, 2012

@theory theory Return max plan index when updating old IDs.
Because, when we had the old IDs, things could be run in an order different
from the plan, the last run change may actually appear before other deployed
changes in the plan. So, as we updated the IDs, figure out which of the
deployed changes appears last in the plan, and use *that* change as the
current position.

Ref #56.
e70741d

@theory theory added a commit that referenced this issue Nov 21, 2012

@theory theory Re-use variable, add comment.
I believe that this will cover the case of old IDs already, as
`$plan->get($id)` already works for old IDs, and we are already falling back
on trying to find a change by name and, where possible, tag. Ref #56.
dd90174
Owner

theory commented Nov 21, 2012

@LAST^ and @FIRST~ made to find relative IDs in the database, rather than the plan, in 4eb1096.

Owner

theory commented Dec 1, 2012

Changed the revert command to search the database for a change, rather than the plan file, by rewriting much of Engine in b0dfab3, e70741d, 34b96ac, dc81610, a90b263, 6f37104, e735d1e, 6050935, and dd59bc6. As a result, I be able to eliminate @LAST and @FIRST, since they are superfluous. It's more likely that a user might want to force a search of the database for any change or tag, not just the first or last change.

Owner

theory commented Dec 1, 2012

Deprecated @FIRST and @LAST in ff6da34.

Owner

theory commented Dec 4, 2012

Made a few tweaks testing it with existing installs, mostly just for esthetic reasons. It's ready to go. Releasing v0.940 tonight.

theory closed this Dec 4, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment