Changes made in this release of OTDB
------------------------------------
The metadata of the trees is extended with 4 fields:
ADD COLUMN groupID INTEGER,
ADD COLUMN processType VARCHAR(20),
ADD COLUMN processSubtype VARCHAR(120),
ADD COLUMN strategy VARCHAR(30);
This has inpact on the treeInfo structure used by several sql functions.
The new treeInfo SQL structure is:
CREATE TYPE treeInfo AS (
treeID INT4, -- OTDBtree.treeID%TYPE,
momID INT4,
>> groupID INT4,
classification INT2, -- classification.ID%TYPE,
creator VARCHAR(20), -- OTDBuser.username%TYPE,
creationDate timestamp(0),
type INT2, -- treetype.ID%TYPE,
state INT2, -- treestate.ID%TYPE,
originalTree INT4, -- OTDBtree.treeID%TYPE,
campaign VARCHAR(30), -- campaign.name%TYPE,
starttime timestamp(0),
stoptime timestamp(0),
>> processType VARCHAR(20),
>> processSubtype VARCHAR(120),
>> strategy VARCHAR(30),
description TEXT
);
The new C++ class is:
class OTDBtree {
public:
OTDBtree() : itsTreeID(0), itsMomID(0) {};
~OTDBtree() {};
treeIDType treeID() const { return (itsTreeID); }
treeIDType momID() const { return (itsMomID); }
>> treeIDType groupID;
classifType classification; // development / test / operational
string creator;
ptime creationDate;
treeType type; // hardware / VItemplate / VHtree
treeState state; // idle / configure / ... / active / ...
>> string processType; // Maintenance / Reservation / Observation / ..
>> string processSubtype; // UVmeasurement / PulsarPipeline / ...
>> string strategy; // restricted free text
string description; // free text
// -- VIC only --
treeIDType originalTree;
string campaign;
ptime starttime;
ptime stoptime;
...
}
The affected functions are:
getTreeGroup
getTreesInPeriod
getExecutableTrees
getTreeInfo
getTreeList
setMomInfo
The interface of the last 2 functions are changed:
getTreeList is extended with the four new fields. Every field is optional.
The new function is:
// getTreeList ([treeType], [classification], [groupID], [processType], [processSubtype], [strategy])
vector<OTDBtree> getTreeList(treeType, classifType, uint32, const string&, const string&, const string&);
setMomInfo is extenden with the groupID:
The new function is:
bool setMomInfo(treeIDType, treeIDType, uint32, string)
// setMomInfo (treeID, MomID, groupID, campaign)
The GroupID's are managed by OTDB, so a new function is added to the database to get a new unique groupID:
uint32 newGroupID();
NOTES NOTES NOTES NOTES NOTES
Since it is not clear yet what values are allowed in the processType, processSubtype and strategy fields
there is no check on the values of the fields yet other than that the combination of them must be unique
for default templates.
The processType fields can only be assigned to template and default-template trees. Trying to assign them
to the other fieldtypes results in an error.
"CEP/Pipeline/recipes/sip/nodes/python_plugin.py" did not exist on "124d9f8157beeb443297b4003c4947e03eb46cd8"
Stefan Froehlich
authored
Task #6559 First experiments with a casapy recipe. Works in basic form for now but with workarounds for proper return values to the pipeline. casapy does not seem to return in a usual way. when there is an error the pipeline does not recognize the process has finished. without the encapsuleting in a shell script even a successful run does not return. Needs more checking and a cleaner way of calling. Maybe integrate casa python classes to the Lofar install? Loops: Nested loops work. Breaking a loop only works for one full cycle. Outputdictionaries you reference with step.output.stepval are now always for the last call of that step.