[Heartlogic-dev] Kwiki wiki page EnsureValidityViaDataIntegrityChecking updated by AnonymousGnome

[wiki]

Kwiki page EnsureValidityViaDataIntegrityChecking edited by AnonymousGnome

--- database/EnsureValidityViaDataIntegrityChecking.old Wed Jun  1 14:03:37 2005
+++ database/EnsureValidityViaDataIntegrityChecking     Wed Jun  1 14:03:37 2005
@@ -5,26 +5,16 @@
 and higher urgency as we move from OpRBP to
 OperationRuminationPilot to OperationRuminationFull.
 
-Here is more detail on this thead from a partially digested email
-conversation circa 2005-05-31
+=== Item Versions
 
-Implemented around 2005-05-31 there are some complicated features of
-how items should be presented.  For example, participants will not be
+Implemented around 2005-05-31 there is a sophisticate feature of
+how items are presented.  Participants will not be
 asked both reversed and unreversed versions of a statement.
 
-How to verify that there are no bugs in this?  It might seem like it
-will require lots of test trials and lots of anality.  But there is an
-easier way...test it on the fly, as we collect data by doing integrity
-tests on the data collected so far.
-
-yes, if there is a bug in something complex like this hopefully we
-will find it in the data.  e.g. make a query like this "give me all
-subjects and all itmes such that that subject has seen the reversed
-and unreversed version of that item."  if we get any hits for a query
-like that we know there is a bug.
+How to verify that there are no bugs in this? 
 
-Joshua suggestsed that in his opinion, the way to verify that we are
-asking an appropriate set of questions is to study the SQL query:
+1. There is only one place in the code where the next item is
+selected.  Here is the SQL query:
 
  SELECT c_stat.construal_id
  FROM c_stat NATURAL JOIN construal
@@ -37,9 +27,18 @@
                           r.construal_id        = rc.construal_id)
     WHERE r.rating_expert_id = ?)
 
-He tested it and it seems to work.  This saves Bill time from having
-to worrying about this.
+Joshua tested it and it seems to work.
 
-Hopefully we will not forget to actully follow through on writing
-these many integrity type queries (not just for bugs with reversal)
-and will have them run automatically as the data rolls in.
+2. A more paranoia approach is to run a regression test to assure
+that each of a given login's ratings refers to at most one parent node.
+(Background:
+Every item has a parent. All versions of the same item have the
+same parent.)
+
+3. Another place where bugs may lurk is the item creation code.
+Currently, the items are created by hand by Bill.  Joshua could
+write a regression test for this by extracting the database into
+a file similar to the file Bill created by hand (for comparison).
+
+4. Once we automate item creation then there may be more chances
+for bugs to creep in.