This post is part of a larger discussion about temporal databases.  Hopefully it stands on it’s own but for more context see the Temporal Database Design page.  You can read the official Wikipedia definition but for our purposes a Temporal Database is a database where you can query for historical data using SQL.  This is work in progress and constructive feedback via e-mail (chris.cumming@saturdaymp.com) is most appreciated.

In a non-temporal database a record dose not change over time.  For example say you have a Contacts table with a name field.

Notes I took while trying to fix the Incomplete Bitcode error in submission bug.  Not sure if it’s fixed yet as I haven’t tried submitting an app to the App Store yet.  Hopefully someone else will try it and confirm it’s fixed.

In summary when submitting an app to iTunes Connect that has the XPlugins.iOS.BEMCheckBox the user got the following error:

ERROR ITMS-90668: “Invalid Bundle Executable. The executable file ‘InstantApp.BoostOrder.Customer.Touch.app/Frameworks/BEMCheckBox.framework/BEMCheckBox’ contains incomplete bitcode. To compile binaries with complete bitcode, open Xcode and choose Archive in the Product menu.”

This post is part of a larger discussion about temporal databases.  Hopefully it stands on it’s own but for more context see the Temporal Database Design page.

Most of us have worked with database tables that track some historical information.  You add a EffectiveDate column or something similar and usually it’s just limited to a table to two.  A Temporal Database is designed so most or all of the tables can track historical information.

The important part is that you can access the historical database using a SQL query and don’t have to look elsewhere, such as audit log.  This is what makes a database a Temporal Database, at least according to me.

Degree of Database Temporalness

A database can either be non-temporal, partial temporal, or fully temporal.  You can measure the temporalness by the percentage of tables that store temporal data.

Non-Temporal (0% Temporalness): Database has no temporal capabilities.

Partially Temporal (1% - 99% Temporalness): The database has some tables store temporal data but not all.

Fully Temporal (100% Temporalness): All the tables in the database store temporal data.

Type of Table Temporalness

We don’t measure how temporal a table is by percentage.  Instead a table is defined by what type of historical data you can retrieve.  There are two types of historical data:

You can read the official Wikipedia definition but for our purposes it’s a database where you can query for historical data using SQL.

For example, say you have someone named Chronos who lives in New York but on April 15, 2012 moves to Hong Kong.  If you don’t have an historical tracking then you will only be able to see that Chronos lives in Hong Kong.  You don’t know where he lived before Hong Kong or when he moved to Hong Kong.

In Part 1 we created a custom NUnit constraint but you where limited in using the constraint.  You could only write:

 
// Instantiate the constraint. 
Assert.That(expected, new EquivalentPropertyWiseToConstraint(actual)); 

// Matches syntax. 
Assert.That(expected, Is.Not.Matches(new EquivalentPropertyWiseToConstraint(actual)));

It would be nice to write:

// Directly access the constraint from Is.
Assert.That(expected, Is.EquivalentPropertyWiseTo(actual));

// Chain the constraint in Is.
Assert.That(expected, Is.Not.EquivalentPropertyWiseTo(actual));

To do that you should read the documentation.  End of blog post.

So is that joke still funny?  No, OK, no more.  Lets get back to what we are doing.  To access the method using Is you need to override the Is class and add a static method.  I recommended making the method name similar to your constraint name.  For example: