Notes for Users of Earlier Versions
First we extract the id (Object Key attribute) then we use Find in Database to check if the object already
exists. If the object exists the current record is loaded into our output object, and we now extract the price
on-top of the previous value, and then we store the object again. If the object was not found by Find in
Database an error is generated, and "Try Next Alternative" error handling sends the execution into the
lower branch where we extract the price, load and extract the details, and then store the object.
The new method may require an extra Extract Price step, but it is much easier to see what happens, and
there is no refind-object-magic.
If your robot has any Query Database or Execute SQL steps which query the storage tables, these may
need to be updated as well.
Migrating Existing Data and Tables
If you have small amounts of data, or you collect all the data every time your robots run, the easiest is
simply to delete (drop) the existing tables, and create new tables using the updated model objects.
If you have large amounts of data, or need the historic data from previous runs, you have to convert your
existing data tables into the new table layout. It is possible to use tools from your database vendor to
add/remove and rename the fields, but it is not recommended. The best solution is to use a robot to load
the old data and store it using the new format.
To do this, create a table from you updated output object; you will have to rename the original data table
unless you have given the new version of the object a different name. Then create a robot which loads the
existing data using the Query Database step action, and stores the objects using Store in Database.
If you require the data history, like first and last Extracted date, you can extract these from the old row,
and use the Execute SQL step to update the object after it has been stored.
If you have exposed the refindKey outside of your Kapow environment, you probably need to track which
ObjectKey maps to an existing refindKey, and then provide the outside world with a mapping table,
allowing them to convert existing refindKeys into the new ObjectKeys. This is important since you can't
always generate an ObjectKey identical to the previous refindKey, since the robotId was often part of the
Migrating SQL Scripts
It is not possible to give a generic rule for how to migrate external SQL scripts, since the possibilities and
complexity of such scripts are virtually endless. Instead we will try to give some guidelines.
Moving production data out of the harvest database
It is not a good idea to run user queries against the harvest tables (the tables the robots collect into),
instead you should have a separate set of tables for the production data. These tables will contain the
refindKey/ObjectKey, but not necessarily any of the other household fields. The production tables usually
should be updated each time a robot has executed successfully.
Previously, the rows to move was often identified by using the robotRunId column to find the most recent
run, but this column no longer exists. Instead we now have a column named LastUpdated, which contains
a timestamp of when this row was last updated. This way all you need to do is find all rows which have
been updated since you last moved data out of the harvest tables. If you have multiple robots harvesting
data into the same table, you now need to use the robotName and not the robotId to distinguish data from
Scripts against RoboManager tables