Schedule

Based on our discussion:

  • We want to send a technical report describing MetPetDB to people
in the geological community that Frank and Joe feel would be interested in using our work.
  • We want to gain feedback about the report by the end of the
semester (important features missing, important use cases scenarios not considered, non-realistic use cases).
  • We want to offer ~4 weeks for reviewers to digest the report
and provide comments.
  • We'd like to have something shiny and partially interactive
that reviewers could poke at to get a feel for the system, more so than what screenshots on paper will do.

So we're talking about mid-April to send out the technical report.

Date #1: Technical report "published" week of April-9th.

Backing up from there, lets assume we need about a week to include polished screenshots in the report, as we should be able to write/update the report's content in parallel with actual shiny-interactive-thing's development.

Date #2: Shiny-interactive-thing week of March-26th.

Since we'd like to offer something that actually is interactive, I think we'd like to push my current Hibernate-Tapestry-Spring prototype of the MetPetDB website into a state that users can make use of it. Therefore I propose the shiny-interactive-thing be that prototype, hosted on samana.cs.rpi.edu.

We need to decide exactly what should be in that by March-26th. Looking at the site map handed out by Joe last week I'm thinking we may be able to include the following:

  • Search Front
    • By mineral
    • By rock type
    • By bounding box
  • Update Front
    • Manually enter new sample (not by spreadsheet)
    • Manually enter new subsample
    • Manually enter new chemical analysis
    • Update sample (owned or in project)
    • Update subsample
    • Update chemical analysis
  • Management Front
    • Create project
    • Add members to project
    • Contribute owned samples to project
Thoughts?

These roughly fall into a schedule such as the following:

By Feb 7th:

    • Manually enter new sample (not by spreadsheet)
    • Manually enter new subsample
By Feb 14th:
    • Manually enter new chemical analysis
By Feb 21st:
    • Search by mineral
    • By rock type
    • By bounding box
By Feb 28st:
    • Create project
    • Add members to project
    • Contribute owned samples to project
By Mar 7th:
    • Update sample (owned or in project)
    • Update subsample
    • Update chemical analysis
I'm intentionally leaving a good part of March open right now, as once we get into implemeting the screens for above and provide something that Frank and Joe can poke at we are probably going to want to make some adjustments, which will wind up setting the schedule back. In software development its a good rule to just double whatever you think the schedule is, because stuff happens.

We also will probably want to spend some time making the site pretty, and adding some of the top level (level 2 on Joe's sitemap) items.

Revision Data

I think Sibel and I may have resolved the issue of storing revision data. Most of the data changes in MetPetDB are addition of new information, which are new rows in the database. Very few cases will update an existing row.

We proposing to make the key of every row a pair of values (realkey, version), where realkey is whatever the real key of the data would have been. The version attribute is an integer where 0 is the current active version, and >0 is a historical record.

Initial inserts will be stored as version = 0. If a future update (or delete) takes place the active version will be updated to be MAX(version) + 1, and a new row will be added to the database with version = 0, to store the new active record.

Accessing the active record will be very quick, as we can hardcode in the version = 0 parameter. Accessing historical records will be somewhat efficient, but to know exactly what field(s) a user modified we will need to perform a field-by-field comparsion in the application once the data has been read from the database.