A very basic level of tracking of the history of a resource is to track the last time the resource was migrated by Wildebeest.
In the case of database resources (MySQL, PostgreSQL, SQL Server) the current state that the resource is in is tracked in a special table - by default named "wb_state" and placed in a schema named "wb".
The logic for tracking state in this table is contained in some simple helper functions per DB type:
Each of these classes has a setStateId() method which handles updating the Wildbeest state ID that is tagged on the database.
The outcome we want is that when the tracked state is updated on a database, we also include the instant (i.e. date/time) when the resource was put into that state.
Those helper classes each also contain a createStateTableIfNotExists() method which creates the table. This will need to be updated to add a column to track the instant when the migration occurred.
Please use the column name "LastMigrationInstant" rather than "DateTime" or "Timestamp". "DateTime" is clumsy and "Timestamp" has special meaning in some DBMS's such as SQL Server where it is a data type. "Instant" is the most accurate term.
The data type for the column should be the equivalent of ANSI SQL "timestamp with time zone":
PostgreSQL - it uses the ANSI SQL data type name - https://www.postgresql.org/docs/9.1/static/datatype-datetime.html
SQL Server - DateTimeOffset - https://docs.microsoft.com/en-us/sql/t-sql/data-types/datetimeoffset-transact-sql?view=sql-server-2017
MySQL - TBD.
Testing for this feature will be the biggest challenge since it needs three DBMS servers to be available. To date I've always tested with these installed locally on my dev workstation and on the build server for CI, but it's time to improve this with Dockerized DBMS containers. Let's discuss how when you're ready.