revi-archive/phorge-phorge
1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-10 08:52:39 +01:00
Code Issues Releases Wiki Activity
phorge-phorge/resources/sql/patches/104.searchkey.sql

16 lines
483 B
MySQL
Raw Normal View History

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 16:53:53 +02:00
ALTER TABLE {$NAMESPACE}_search.search_query
Use a unique random key to identify queries, not a sequential ID Summary: We save search information and then redirect to a "/search/<query_id>/" URI in order to make search URIs short and bookmarkable, and save query data for analysis/improvement of search results. Currently, there's a vague object enumeration security issue with using sequential IDs to identify searches, where non-admins can see searches other users have performed. This isn't really too concerning but we lose nothing by using random keys from a large ID space instead. - Drop 'authorPHID', which was unused anyway, so searches can not be personally identified, even by admins. - Identify searches by random hash keys, not sequential IDs. - Map old queries' keys to their IDs so we don't break any existing bookmarked URIs. Test Plan: Ran several searches, got redirected to URIs with random hashes from a large ID space rather than sequential integers. Reviewers: arice, btrahan Reviewed By: arice CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1587
2012-02-07 23:58:46 +01:00
DROP authorPHID;
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 16:53:53 +02:00
ALTER TABLE {$NAMESPACE}_search.search_query
Use a unique random key to identify queries, not a sequential ID Summary: We save search information and then redirect to a "/search/<query_id>/" URI in order to make search URIs short and bookmarkable, and save query data for analysis/improvement of search results. Currently, there's a vague object enumeration security issue with using sequential IDs to identify searches, where non-admins can see searches other users have performed. This isn't really too concerning but we lose nothing by using random keys from a large ID space instead. - Drop 'authorPHID', which was unused anyway, so searches can not be personally identified, even by admins. - Identify searches by random hash keys, not sequential IDs. - Map old queries' keys to their IDs so we don't break any existing bookmarked URIs. Test Plan: Ran several searches, got redirected to URIs with random hashes from a large ID space rather than sequential integers. Reviewers: arice, btrahan Reviewed By: arice CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1587
2012-02-07 23:58:46 +01:00
ADD queryKey VARCHAR(12) NOT NULL;
/* Preserve URIs for old queries in case anyone has them bookmarked. */
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 16:53:53 +02:00
UPDATE {$NAMESPACE}_search.search_query
Use a unique random key to identify queries, not a sequential ID Summary: We save search information and then redirect to a "/search/<query_id>/" URI in order to make search URIs short and bookmarkable, and save query data for analysis/improvement of search results. Currently, there's a vague object enumeration security issue with using sequential IDs to identify searches, where non-admins can see searches other users have performed. This isn't really too concerning but we lose nothing by using random keys from a large ID space instead. - Drop 'authorPHID', which was unused anyway, so searches can not be personally identified, even by admins. - Identify searches by random hash keys, not sequential IDs. - Map old queries' keys to their IDs so we don't break any existing bookmarked URIs. Test Plan: Ran several searches, got redirected to URIs with random hashes from a large ID space rather than sequential integers. Reviewers: arice, btrahan Reviewed By: arice CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1587
2012-02-07 23:58:46 +01:00
SET queryKey = 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 16:53:53 +02:00
ALTER TABLE {$NAMESPACE}_search.search_query
Use a unique random key to identify queries, not a sequential ID Summary: We save search information and then redirect to a "/search/<query_id>/" URI in order to make search URIs short and bookmarkable, and save query data for analysis/improvement of search results. Currently, there's a vague object enumeration security issue with using sequential IDs to identify searches, where non-admins can see searches other users have performed. This isn't really too concerning but we lose nothing by using random keys from a large ID space instead. - Drop 'authorPHID', which was unused anyway, so searches can not be personally identified, even by admins. - Identify searches by random hash keys, not sequential IDs. - Map old queries' keys to their IDs so we don't break any existing bookmarked URIs. Test Plan: Ran several searches, got redirected to URIs with random hashes from a large ID space rather than sequential integers. Reviewers: arice, btrahan Reviewed By: arice CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1587
2012-02-07 23:58:46 +01:00
ADD UNIQUE KEY (queryKey);
Add a safeguard against multiple patches with the same version Summary: I accidentally added two "104" patches. This actually works OK for the most part but is fundamentally bad and wrong. Merge the patches (installs applied both as "104", so we can't move one to "105") and add a safeguard. Test Plan: Ran upgrade_schema.php with two "104" patches, got error'd. Ran without, got successs. Reviewers: btrahan Reviewed By: btrahan CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1614
2012-02-15 01:24:02 +01:00
/* NOTE: Accidentally added this as 104, merging. */
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 16:53:53 +02:00
UPDATE {$NAMESPACE}_project.project SET status = IF(status = 5, 100, 0);
Copy permalink