Remove Dummy Package concept

Instead, we just store dependencies directly in the PackageDepends
table. Since we don't use this info anywhere besides the package details
page, there is little value in precalculating what is in the AUR vs.
what is not.

An upgrade path is provided via several SQL statements in the UPGRADING
document. There should be no user-visible change from this, but the DB
schema gets a bit more sane and we no longer have loads of junk packages
in our tables that are never shown to the end user. This should also
help the MySQL query planner in several cases as we no longer have to be
careful to exclude dummy packages on every query.

Signed-off-by: Dan McGee <dan@archlinux.org>
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de>

1 files changed, 12 insertions, 0 deletions

diff --git a/UPGRADING b/UPGRADING
index 4743b8e..e6590f0 100644
--- a/UPGRADING
+++ b/UPGRADING
@@ -8,6 +8,18 @@ From 1.8.1 to X.X.X
 
 UPDATE Packages SET ModifiedTS = SubmittedTS WHERE ModifiedTS = 0;
 
+2. Move to new method of storing package depends.
+
+----
+ALTER TABLE PackageDepends ADD COLUMN DepName VARCHAR(64) NOT NULL DEFAULT '' AFTER PackageID;
+UPDATE PackageDepends SET DepName = (SELECT Name FROM Packages WHERE ID = DepPkgID);
+ALTER TABLE PackageDepends MODIFY DepName VARCHAR(64) NOT NULL;
+ALTER TABLE PackageDepends DROP FOREIGN KEY `PackageDepends_ibfk_2`;
+ALTER TABLE PackageDepends DROP COLUMN DepPkgID;
+DELETE FROM Packages WHERE DummyPkg = 1;
+ALTER TABLE Packages DROP COLUMN DummyPkg;
+----
+
 From 1.8.0 to 1.8.1
 -------------------