Changes between Version 2 and Version 3 of Server/Setup

07/12/12 10:19:16 (8 years ago)

Added documentation for admins; how to get the datamodel modified


  • Server/Setup

    v2 v3  
     19The script is a project specific wrapper of [], which is automaticaly created in each Django project.
    2022== Basic Apache configuration ==
    2830The first bit has to be the URL you want to be serving CMT at, and the second is the location of the WSGI-file in the CMT project directory.
    2931Any request below the given URL will be served using the application that's definined in the WSGI-file.
     35= Changes in datamodel =
     37Thanks to introspection by the South package, it's possible to dynamicly modify the datamodel.
     38South will make migration-files for you, which are stored in their own directory, defined in the settings-file of CMT.
     41== Initial migration ==
     43To make the initial migration:
     46python schemamigration <appname> --initial
     49In case of the cluster application in CMT it should print output like:
     52+ Added model 'cluster.InterfaceType'
     53 + Added model 'cluster.HardwareSpecifications'
     55 + Added model 'cluster.WarrantyContract'
     56 + Added model 'cluster.Connection'
     57 + Added M2M 'cluster.Company.buildings'
     58 + Added M2M 'cluster.HardwareUnit.role'
     59 + Added unique_together for [firstname, lastname] on Connection.
     60 + Added unique_together for [rack, first_slot] on HardwareUnit.
     61 + Added unique_together for [address, floor, label] on Room.
     62 + Added unique_together for [address1, city] on Address.
     66This results in an initial migration file, consisting of Python code which:
     67* creates a database table based on each added model
     68* set relationships between the tables, based on the datamodel
     69* set constraints for the database tables
     71Every time when a migration has been created it should be used to get the database tables synchronized. Because the initial migration is a diff from zero to the initial setup (which has already been done with the ./ syncdb command), the migration has to be faked. To fake a migration:
     74python migrate <appname> --fake
     77Its output confirms that the database is already in sync with the datamodel:
     80Running migrations for cluster:
     81- Nothing to migrate.
     85== Migrations on changes ==
     87Once the datamodel has been changed you have to generate a new migration, which should be runned to keep the database in sync.
     89=== Generate migration ===
     91A migration should be generated by issuing the following command:
     93python manage schemamigration <appname> <migrationname> --auto
     97  ''There was a model Connection with two fields that hold a telephonenumber, but those fields has been replaced by a foreign key in the table of the Telephone model; in that case the command could look like''
     99python schemamigration cluster telephone --auto
     101  ''which should give an output like''
     103 + Added field 'cluster.telephonenumber.connection'
     104 - Deleted field ''
     105 - Deleted field 'cluster.connection.cellphone'
     108  ''In this case a migration-file (called has been saved in the migration-directory.''
     110=== Run migration ===
     112Run a migration to migrate the database to the most recent changes by issuing the command:
     114python migrate <appname>
     118  ''In case of the generated migration of the previous example, the command should look like''
     120python migrate cluster
     122  ''which should give an output like''
     124Running migrations for cluster:
     125 - Migrating forwards to 0002_telephone.
     126 > cluster: 0002_telephone
     127   = ALTER TABLE "cluster_telephonenumber" ADD COLUMN "connection_id" integer NOT NULL; []
     128   = DROP TABLE "cluster_connection_phone" CASCADE; []
     129   = DROP TABLE "cluster_connection_cellphone" CASCADE; []
     130   = ALTER TABLE "cluster_telephonenumber" ADD CONSTRAINT "connection_id_refs_id_1741ef3" FOREIGN KEY ("connection_id") REFERENCES "cluster_connection" ("id") DEFERRABLE INITIALLY DEFERRED; []
     131   = CREATE INDEX "cluster_telephonenumber_connection_id" ON "cluster_telephonenumber" ("connection_id"); []
     132 - Loading initial data for cluster.
     134  ''As you can see there has been executed some SQL-statements, which reflect the changes in the datamodel.''