phabricator/resources/sql/patches/029.cursors.sql

ALTER TABLE {$NAMESPACE}_timeline.timeline_event
  ADD dataID int unsigned;

ALTER TABLE {$NAMESPACE}_timeline.timeline_event
  ADD UNIQUE KEY (dataID);

UPDATE {$NAMESPACE}_timeline.timeline_event e,
       {$NAMESPACE}_timeline.timeline_eventdata d
  SET e.dataID = d.id
  WHERE d.eventID = e.id;

ALTER TABLE {$NAMESPACE}_timeline.timeline_eventdata
  DROP eventID;
SQL Patch Management: SQL Changes Summary: Splits out the SQL changes. These are most of the changes, but primarily mechanical: - Moved "initialize.sql" to "0000.legacy.sql" and partially reverted to an older version, such that patches 0000 + 000 + 001 + ... + 137 put us in the right state when applied sequentially. - Removed "create database" commands from all SQL. These are handled by separate DB patches now, so we have the data to do operations like "storage databases" (list databases) and "storage destroy" (drop databases). - Removed "phabricator_" namespace from all SQL, and replaced with "{$NAMESPACE}_" token so we can namespace databases. - Shortened some column lengths so patches apply correctly if originally created as InnoDB; also a few similar tweaks elsewhere. Test Plan: See D2323 for discussion and test plan. Reviewers: edward, vrana, btrahan, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T140, T345 Differential Revision: https://secure.phabricator.com/D2329 2012-04-30 07:53:53 -07:00			`ALTER TABLE {$NAMESPACE}_timeline.timeline_event`
Avoid Timeline race condition Summary: While I should fix the transactional stuff, that patch is going to be tricky and transactions have some performance implications. This is a simple fix which prevents the race. Instead of having the data point at the event ID, have the event point at a data ID. Insert the data first, then insert the event with the right data pointer. This is super simple and prevents the race issue. Test Plan: - Ran the schema upgrade script, verified that the database was correctly upgraded. Was also prompted to stop daemons. - Ran 'repository-launch-master', verified that the discovery daemons were able to discover new commits and insert events for them. Verified the committask daemon was consuming events and converting them into tasks. - Verified new tasks looked correct in the database. - Browsed web interface. Reviewers: jungejason CC: tuomaspelkonen Differential Revision: 133 2011-04-14 09:41:43 -07:00			`ADD dataID int unsigned;`

SQL Patch Management: SQL Changes Summary: Splits out the SQL changes. These are most of the changes, but primarily mechanical: - Moved "initialize.sql" to "0000.legacy.sql" and partially reverted to an older version, such that patches 0000 + 000 + 001 + ... + 137 put us in the right state when applied sequentially. - Removed "create database" commands from all SQL. These are handled by separate DB patches now, so we have the data to do operations like "storage databases" (list databases) and "storage destroy" (drop databases). - Removed "phabricator_" namespace from all SQL, and replaced with "{$NAMESPACE}_" token so we can namespace databases. - Shortened some column lengths so patches apply correctly if originally created as InnoDB; also a few similar tweaks elsewhere. Test Plan: See D2323 for discussion and test plan. Reviewers: edward, vrana, btrahan, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T140, T345 Differential Revision: https://secure.phabricator.com/D2329 2012-04-30 07:53:53 -07:00			`ALTER TABLE {$NAMESPACE}_timeline.timeline_event`
Avoid Timeline race condition Summary: While I should fix the transactional stuff, that patch is going to be tricky and transactions have some performance implications. This is a simple fix which prevents the race. Instead of having the data point at the event ID, have the event point at a data ID. Insert the data first, then insert the event with the right data pointer. This is super simple and prevents the race issue. Test Plan: - Ran the schema upgrade script, verified that the database was correctly upgraded. Was also prompted to stop daemons. - Ran 'repository-launch-master', verified that the discovery daemons were able to discover new commits and insert events for them. Verified the committask daemon was consuming events and converting them into tasks. - Verified new tasks looked correct in the database. - Browsed web interface. Reviewers: jungejason CC: tuomaspelkonen Differential Revision: 133 2011-04-14 09:41:43 -07:00			`ADD UNIQUE KEY (dataID);`

SQL Patch Management: SQL Changes Summary: Splits out the SQL changes. These are most of the changes, but primarily mechanical: - Moved "initialize.sql" to "0000.legacy.sql" and partially reverted to an older version, such that patches 0000 + 000 + 001 + ... + 137 put us in the right state when applied sequentially. - Removed "create database" commands from all SQL. These are handled by separate DB patches now, so we have the data to do operations like "storage databases" (list databases) and "storage destroy" (drop databases). - Removed "phabricator_" namespace from all SQL, and replaced with "{$NAMESPACE}_" token so we can namespace databases. - Shortened some column lengths so patches apply correctly if originally created as InnoDB; also a few similar tweaks elsewhere. Test Plan: See D2323 for discussion and test plan. Reviewers: edward, vrana, btrahan, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T140, T345 Differential Revision: https://secure.phabricator.com/D2329 2012-04-30 07:53:53 -07:00			`UPDATE {$NAMESPACE}_timeline.timeline_event e,`
			`{$NAMESPACE}_timeline.timeline_eventdata d`
Avoid Timeline race condition Summary: While I should fix the transactional stuff, that patch is going to be tricky and transactions have some performance implications. This is a simple fix which prevents the race. Instead of having the data point at the event ID, have the event point at a data ID. Insert the data first, then insert the event with the right data pointer. This is super simple and prevents the race issue. Test Plan: - Ran the schema upgrade script, verified that the database was correctly upgraded. Was also prompted to stop daemons. - Ran 'repository-launch-master', verified that the discovery daemons were able to discover new commits and insert events for them. Verified the committask daemon was consuming events and converting them into tasks. - Verified new tasks looked correct in the database. - Browsed web interface. Reviewers: jungejason CC: tuomaspelkonen Differential Revision: 133 2011-04-14 09:41:43 -07:00			`SET e.dataID = d.id`
			`WHERE d.eventID = e.id;`

SQL Patch Management: SQL Changes Summary: Splits out the SQL changes. These are most of the changes, but primarily mechanical: - Moved "initialize.sql" to "0000.legacy.sql" and partially reverted to an older version, such that patches 0000 + 000 + 001 + ... + 137 put us in the right state when applied sequentially. - Removed "create database" commands from all SQL. These are handled by separate DB patches now, so we have the data to do operations like "storage databases" (list databases) and "storage destroy" (drop databases). - Removed "phabricator_" namespace from all SQL, and replaced with "{$NAMESPACE}_" token so we can namespace databases. - Shortened some column lengths so patches apply correctly if originally created as InnoDB; also a few similar tweaks elsewhere. Test Plan: See D2323 for discussion and test plan. Reviewers: edward, vrana, btrahan, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T140, T345 Differential Revision: https://secure.phabricator.com/D2329 2012-04-30 07:53:53 -07:00			`ALTER TABLE {$NAMESPACE}_timeline.timeline_eventdata`
Avoid Timeline race condition Summary: While I should fix the transactional stuff, that patch is going to be tricky and transactions have some performance implications. This is a simple fix which prevents the race. Instead of having the data point at the event ID, have the event point at a data ID. Insert the data first, then insert the event with the right data pointer. This is super simple and prevents the race issue. Test Plan: - Ran the schema upgrade script, verified that the database was correctly upgraded. Was also prompted to stop daemons. - Ran 'repository-launch-master', verified that the discovery daemons were able to discover new commits and insert events for them. Verified the committask daemon was consuming events and converting them into tasks. - Verified new tasks looked correct in the database. - Browsed web interface. Reviewers: jungejason CC: tuomaspelkonen Differential Revision: 133 2011-04-14 09:41:43 -07:00			`DROP eventID;`