Web Application Organization

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.

Data Storage

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.

Data Import

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:

1. General Usefulness: If the information can potentially or actually be used by multiple applications, then this criterion suggests putting it in uwdata. If the information is very specific to a specific application, then this criterion suggests putting it in that application.
2. Confidentiality: If the information is confidential, this criterion suggests putting it the specific application that needs it in order to make access control easier. If the information is public, putting it in 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.

Source Code Repository

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