Here we describe the application organization being developed for the OGSAS system. The part described here, however, is meant to apply to future web application projects. It appears likely that there will eventually be numerous web application projects, so we should have some common practices where appropriate to provide consistency and avoid having to keep making architectural decisions over and over.
We will share Postgres database installations between multiple applications. There will be two databases, one for production and one for development/testing. In future we may split testing from development, as we develop proper regression test procedures.
The two databases will have the same structure, with (normally) one schema per application. Normally, all application related data will be stored in the Postgres database. Under some circumstances, an application may have voluminous file data associated with it. In this case, direct file system storage of the information may be considered, but only if the developers involved understand the database “BYTEA” data type and are making an informed decision not to use it.
Within each application schema, sets of tables may be kept separate by the use of a prefix ending with an underscore. This is appropriate anytime there are multiple distinct groups of tables used in very different ways by parts of the same application, or if the data in the tables have different ownership.
Often, much of the information required by an application is obtained from other parts of the University or even outside the University. This is normally handled by a cronjob on cscf.cs
. There is a special uwdata
application which simply stores information imported from the rest of the University.
In the event that a new data feed is required, there is a question as to whether it should be added to uwdata
or if instead it should simply be a part of the relevant application. The decision can be taken on two criteria:
uwdata
. If the information is very specific to a specific application, then this criterion suggests putting it in that application.
uwdata
is suggested.
Some judgement is required here. uwdata
is not public as a whole, although some of it is. So both criteria must be considered to be fuzzy criteria.
Each distinct set of imported data should be assigned its own table name prefix, whether it is in uwdata
or in an application-specific schema. Furthermore, the tables imported from elsewhere should store only the imported data.
New applications can share a single Subversion source code repository. The root of the repository is currently at svn+ssh://odyssey@core.cs/u/odyssey/svn/odyssey
.
Under this we will have a directory for each application. Each application directory will be organized according to the following template, as applicable:
[appName]/branches
— Branches, as per Subversion recommendations, but only if actually needed.
[appName]/tags/[date]
— The version of the application deployed on the indicated date, in ISO YYYY-MM-DD format. This is also per Subversion recommendations.
[appName]/trunk
— The main focus of development, as per the Subversion recommendations.
[appName]/trunk/sql
— SQL command files to create the application schema from scratch.
[appName]/trunk/python
— Python (+ webpy) code to implement the web application.
[appName]/trunk/doc
— Any appropriate documentation files that should be in the repository. Normally this should be source files only—for example, checking in a .png
E-R diagram obtained from a .dia
document doesn't make much sense.
-- IsaacMorland - 18 Sep 2007