1. Home
  2. Forums
  3. About the AAVSO
  4. VStar

New AID table columns coming?

David Benn
Affiliation
Astronomical Society of South Australia (ASSAU)
Tue, 04/12/2011 - 12:49

Hi all

I read just now in this interesting article:

  http://www.aavso.org/archival-data-digitization-work-progress

that there are plans to add new columns to the AID tables. From Matthew Templeton:

 

The AAVSO Science Team also had a brainstorming session earlier this week to make some changes to the AAVSO International Database, and one of the results is that we'll be adding some new fields to our data tables including columns for a reference (to indicate if the observation was taken from a published paper), and also a column for a digitizer's initials.  Keeping track of the digitizer (in the same way that we tag each observation with an observer code) will allow us to keep track of how the data are entered and (importantly) to give credit to the valuable work that our digitizers are doing.  Most of these changes will be transparent to AAVSO observers and to people using our data, although those who download data will now know the origins of digitized data as well as have identifying information for the people who digitized it.

No doubt, VStar, Zapper and other software could make use of these additional columns when showing the details of observations.

Regards,

David

 

Fri, 09/09/2011 - 15:10
After a busy summer, Doc

After a busy summer, Doc Kinne and I are beginning to perform our planned updates to the aid.observations table.  We have not yet implemented any changes,  but we're planning the following modifications:

  • observations.unique_id will be INT(12) (currently INT(9))
  • several fields currently allowed to be NULL will require a value (including AUID and JD)
  • the observations.valflag enum will have two additional values appended: 'N' for "no valflag" (replacing null), and 'U' for "unvalidated" (replacing blank)
  • the observations.source enum will have three additional values appended: 'K' for VPhot (planned); 'O' for the original database insert from 2005-2006; and 'A' for Archival data entry tool (planned)
  • Two new columns will be added: observations.digitizer (varchar(5)) and observations.pubref (varchar(30))

We'll be in touch with our external developers shortly before these changes are implemented, but as of right now, they should not affect those accessing AAVSO data.  The primary impact will be internal, particularly when we deal with the issue of NULL values.

David Benn
Affiliation
Astronomical Society of South Australia (ASSAU)
Tue, 10/25/2011 - 12:24
Hi Matt

Thanks for the

Hi Matt

Thanks for the heads-up. Is this the change that's happening on Oct 25? 

From VStar's viewpoint, everything should still work after the schema change. The observations.valflag enum handling should be changed to account for the two new values. Is "unvalidated" (U) the same as "pre-validated" (Z)? 

As part of the change, will the database be updated to replace all occurrences of blank with 'U' and null with 'N'?

Will the default values for observations.digitizer be null?

Thanks.

Regards,

David

Tue, 10/25/2011 - 15:20
Hi David,


We're making

Hi David,

We're making *some* of these changes on October 25, yes.  We're holding off on forcing some of the columns to be non-NULL since that will require that we check over all of the WebObs and Zap related codes that do edits and inserts.

Regarding the new valflags, no, the 'U' and 'N' valflags are not related to the prevalidation 'Z' flag -- they stand for 'unvalidated' and 'no valflag' respectively.  The former is required because there are some sets of data not validated during the original validation project (mainly the Orion variables).  The latter is intended to be a temporary valflag to deal with current data without valflags -- I eventually want the 'N' flags to go away.  We are still deciding what to do with the 'U' flagged data.

Regarding the new aid.digitizer column, NULL values will be allowed, as will aid.pubref -- the majority of datain the AID will not have digitizer/pubref values, so it makes sense to leave it NULL.

 

Matt