Support/Developer Tips: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
m (→‎Download Cache: .zsh -> .zshrc)
(adding migration section)
Line 1: Line 1:
Here are a few tips and tricks we've accumulated while working on the [[Support/Kitsune|new platform]]. Hopefully these are helpful to new developers or other contributors who want to get Kitsune up and running to hack on it.
Here are a few tips and tricks we've accumulated while working on the [[Support/Kitsune|new platform]]. Hopefully these are helpful to new developers or other contributors who want to get Kitsune up and running to hack on it.
== Migrations ==
We use schema migrations to maintain our database structure. This allows us to keep a version history of the database (at least since the beginning of Kitsune).
All our migrations are kept in the <code>/migrations/</code> folder, and start with a number. When adding a new migration, it needs to be the next in the sequence. So, for example, if the highest-numbered migration is 12, the next should be named <code>13-some-description.sql</code>.
We have tools to help generate a migration&mdash;they're not perfect, but they get you started.
=== <code>sqlall</code> ===
When you add a new app to the <code>INSTALLED_APPS</code> tuple, you can use the <code>sqlall</code> command to generate a migration.
./manage.py sqlall &lt;app-name&gt;
The resulting SQL will be pretty close to what you need. (You can drop the <code>BEGIN;</code> and <code>COMMIT;</code> statements, as schematic uses transactions automatically.)
=== <code>sqldiff</code> ===
If you are making changes to a model in an app that already exists, you can use the <code>sqldiff</code> command to get the difference:
./manage.py sqldiff &lt;app-name&gt;
The resulting SQL will contain a lot more than you really need: it <code>ALTER</code>s every column. You should drop any statement that doesn't actually change anything, to make it easier for reviewers.


== pip ==
== pip ==

Revision as of 18:10, 23 June 2010

Here are a few tips and tricks we've accumulated while working on the new platform. Hopefully these are helpful to new developers or other contributors who want to get Kitsune up and running to hack on it.

Migrations

We use schema migrations to maintain our database structure. This allows us to keep a version history of the database (at least since the beginning of Kitsune).

All our migrations are kept in the /migrations/ folder, and start with a number. When adding a new migration, it needs to be the next in the sequence. So, for example, if the highest-numbered migration is 12, the next should be named 13-some-description.sql.

We have tools to help generate a migration—they're not perfect, but they get you started.

sqlall

When you add a new app to the INSTALLED_APPS tuple, you can use the sqlall command to generate a migration.

./manage.py sqlall <app-name>

The resulting SQL will be pretty close to what you need. (You can drop the BEGIN; and COMMIT; statements, as schematic uses transactions automatically.)

sqldiff

If you are making changes to a model in an app that already exists, you can use the sqldiff command to get the difference:

./manage.py sqldiff <app-name>

The resulting SQL will contain a lot more than you really need: it ALTERs every column. You should drop any statement that doesn't actually change anything, to make it easier for reviewers.

pip

pip is a package manager for Python that is an improvement over easy_install. It works well with virtualenv, which we also use. (In fact, virtualenv installs pip for you.)

Download Cache

A download cache can make pip install go much faster. There are just two steps to start using a download cache:

mkdir ~/.pip-cache
export PIP_DOWNLOAD_CACHE=~/.pip-cache

You probably want to put the second line into your .bashrc (or .zshrc) file as well, so it's automatically exported when you open the terminal.