The Rel Forum

Hi,

I am not sure whether this is a feature or not, but given the following (same as previous bug-posts):

TYPE Pt POSSREP {X RATIONAL, Y RATIONAL};
TYPE L# POSSREP {L# CHAR};
TYPE LINESEG POSSREP { LINESEG RELATION {Pt Pt}};

VAR P BASE RELATION {Pt Pt} KEY {Pt};
VAR L BASE RELATION {L# L#} KEY {L#};
VAR LP BASE RELATION {L# L#, Pt Pt} KEY {L#, Pt};

// points
P := RELATION {
TUPLE {Pt Pt(0.0,0.0)},
TUPLE {Pt Pt(0.0,1.0)},
TUPLE {Pt Pt(1.0,0.0)},
TUPLE {Pt Pt(1.0,1.0)}
};

// LP (WHICH POINTS ARE IN WHICH LINESEGMENTS)
//CONSTRAINT LS_CON COUNT(LSPOINTS) = 2;

// line segment id numbers
L := RELATION {
TUPLE {L# L#("L1")},
TUPLE {L# L#("L2")},
TUPLE {L# L#("L3")},
TUPLE {L# L#("L4")},
TUPLE {L# L#("L5")}
};

// linesegment has points
LP := RELATION {
TUPLE {L# L#("L1"),Pt Pt(0.0,0.0)},
TUPLE {L# L#("L1"), Pt Pt(0.0,1.0)},
TUPLE {L# L#("L2"), Pt Pt(0.0,1.0)},
TUPLE {L# L#("L2"), Pt Pt(1.0,1.0)},
TUPLE {L# L#("L3"), Pt Pt(1.0,1.0)},
TUPLE {L# L#("L3"), Pt Pt(1.0,0.0)},
TUPLE {L# L#("L4"), Pt Pt(1.0,0.0)},
TUPLE {L# L#("L4"), Pt Pt(0.0,0.0)}
};

it is possible to define a virtual relvar as follows:

VAR LP2 VIRTUAL (EXTEND LP{L#} ADD (LINESEG(RELATION{ TUPLE{L# L#} } COMPOSE LP) AS LINESEG));

with output:

RELATION {L# L#, LINESEG LINESEG} {
TUPLE {L# L#("L1"), LINESEG LINESEG(RELATION {
TUPLE {Pt Pt(0.0, 0.0)},
TUPLE {Pt Pt(0.0, 1.0)}
})},
TUPLE {L# L#("L2"), LINESEG LINESEG(RELATION {
TUPLE {Pt Pt(0.0, 1.0)},
TUPLE {Pt Pt(1.0, 1.0)}
})},
TUPLE {L# L#("L3"), LINESEG LINESEG(RELATION {
TUPLE {Pt Pt(1.0, 0.0)},
TUPLE {Pt Pt(1.0, 1.0)}
})},
TUPLE {L# L#("L4"), LINESEG LINESEG(RELATION {
TUPLE {Pt Pt(0.0, 0.0)},
TUPLE {Pt Pt(1.0, 0.0)}
})},
TUPLE {L# L#("L5"), LINESEG LINESEG(RELATION {
TUPLE {Pt Pt(0.0, 0.0)}
})}
}

the interesting thing is that you can make the added column of a type LINESEG, which did not yet occur in the base relvars.

it's probably bad practice, but it allows using a new type (here: LINESEG) in a virtual relvar LP2 while the Point data that is introduced while creating a LINESEG relation is stored in the other base relvar P (no redundancy of points). It circumvents the problem that when the type LINESEG is an attribute of the base relvar LP the points defined in a particular LINESEG value cannot be queried from the table P even though they do exist and as such should be present in P

what is your opinion?

it works, given of course also the foreign key constraints:

CONSTRAINT LP_L_KEY LP {L#} <= L {L#};
CONSTRAINT LP_P_KEY LP {Pt} <= P {Pt};

Perhaps I'm misunderstanding the issue, but to me it seems perfectly acceptable to be able to create virtual relvars that employ types which are not used in the referenced base relvars.

Ok, I have not read that it was not possible, but it seemed a bit peculiar. However then I get at least two exception handler statments when I do the following:

something like we have a collection of linesegments C (which could for example include polylines or polygones:

TYPE C# POSSREP {C# CHAR};

VAR C BASE RELATION {C# C#} KEY {C#};
C := RELATION {
TUPLE {C# C#("C1")},
TUPLE {C# C#("C2")}
};

# the collection of CL holds particular lineseg ids
VAR CL BASE RELATION {C# C#, L# L#} KEY {C#, L#};

CL := RELATION {
TUPLE {C# C#("C1"), L# L#("L1")},
TUPLE {C# C#("C1"), L# L#("L2")},
TUPLE {C# C#("C2"), L# L#("L3")},
TUPLE {C# C#("C2"), L# L#("L4")}
};

CONSTRAINT CL_L_KEY CL {L#} <= L {L#};
CONSTRAINT CL_C_KEY CL {C#} <= C {C#};

// again the virtual relvar LP2

VAR LP2 VIRTUAL (EXTEND LP{L#} ADD (LINESEG(RELATION{ TUPLE{L# L#} } COMPOSE LP) AS LINESEG));

// when i do the following:

(LP2 join CL) group ({L#,LINESEG} as LS)

I get:

RELATION {C# C#, LS RELATION {L# L#, LINESEG LINESEG}} {
TUPLE {C# C#("C1"), LS RELATION {ERROR: TempStorageTuples: put tuple failed: java.io.NotSerializableException: ca.mb.armchair.rel3.storage.RelDatabase
ca.mb.armchair.rel3.exceptions.ExceptionFatal: TempStorageTuples: put tuple failed: java.io.NotSerializableException: ca.mb.armchair.rel3.storage.RelDatabase
at ca.mb.armchair.rel3.storage.TempStorageTuples.put(TempStorageTuples.java:75)
at ca.mb.armchair.rel3.values.ValueRelation$9$1.hasNextPair(ValueRelation.java:350)
at ca.mb.armchair.rel3.values.ValueRelation$9$1.hasNext(ValueRelation.java:365)
at ca.mb.armchair.rel3.values.ValueRelation$3$1.hasNext(ValueRelation.java:109)
at ca.mb.armchair.rel3.values.TupleIteratorUnique.hasNext(TupleIteratorUnique.java:25)
at ca.mb.armchair.rel3.values.ValueRelation.toStream(ValueRelation.java:625)
at ca.mb.armchair.rel3.values.ValueTuple.toStream(ValueTuple.java:99)
at ca.mb.armchair.rel3.values.ValueRelation.toStream(ValueRelation.java:630)
at ca.mb.armchair.rel3.interpreter.Evaluation.toStream(Evaluation.java:22)
at ca.mb.armchair.rel3.client.stream.ClientLocalConnection$1.execute(ClientLocalConnection.java:69)
at ca.mb.armchair.rel3.client.stream.ClientLocalConnection.send(ClientLocalConnection.java:42)
at ca.mb.armchair.rel3.client.stream.ClientLocalConnection.sendEvaluate(ClientLocalConnection.java:67)
at ca.mb.armchair.rel3.client.string.ClientLocal.sendEvaluate(ClientLocal.java:52)
at ca.mb.armchair.rel3.dbrowser.ui.PanelCommandline$36.doInBackground(PanelCommandline.java:1136)
at javax.swing.SwingWorker$1.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at javax.swing.SwingWorker.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

also if I do:

CL join LP2

I get:

RELATION {C# C#, L# L#, LINESEG LINESEG} {ERROR: TempStorageTuples: put tuple failed: java.io.NotSerializableException: ca.mb.armchair.rel3.storage.RelDatabase
ca.mb.armchair.rel3.exceptions.ExceptionFatal: TempStorageTuples: put tuple failed: java.io.NotSerializableException: ca.mb.armchair.rel3.storage.RelDatabase
at ca.mb.armchair.rel3.storage.TempStorageTuples.put(TempStorageTuples.java:75)
at ca.mb.armchair.rel3.values.ValueRelation$9$1.hasNextPair(ValueRelation.java:350)
at ca.mb.armchair.rel3.values.ValueRelation$9$1.hasNext(ValueRelation.java:365)
at ca.mb.armchair.rel3.values.ValueRelation.toStream(ValueRelation.java:625)
at ca.mb.armchair.rel3.interpreter.Evaluation.toStream(Evaluation.java:22)
at ca.mb.armchair.rel3.client.stream.ClientLocalConnection$1.execute(ClientLocalConnection.java:69)
at ca.mb.armchair.rel3.client.stream.ClientLocalConnection.send(ClientLocalConnection.java:42)
at ca.mb.armchair.rel3.client.stream.ClientLocalConnection.sendEvaluate(ClientLocalConnection.java:67)
at ca.mb.armchair.rel3.client.string.ClientLocal.sendEvaluate(ClientLocal.java:52)
at ca.mb.armchair.rel3.dbrowser.ui.PanelCommandline$36.doInBackground(PanelCommandline.java:1136)
at javax.swing.SwingWorker$1.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at javax.swing.SwingWorker.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

LP2 join CL seems to work...

RELATION {L# L#, LINESEG LINESEG, C# C#} {
TUPLE {L# L#("L1"), LINESEG LINESEG(RELATION {
TUPLE {Pt Pt(0.0, 0.0)},
TUPLE {Pt Pt(0.0, 1.0)}
}), C# C#("C1")},
TUPLE {L# L#("L2"), LINESEG LINESEG(RELATION {
TUPLE {Pt Pt(0.0, 1.0)},
TUPLE {Pt Pt(1.0, 1.0)}
}), C# C#("C1")},
TUPLE {L# L#("L3"), LINESEG LINESEG(RELATION {
TUPLE {Pt Pt(1.0, 0.0)},
TUPLE {Pt Pt(1.0, 1.0)}
}), C# C#("C2")},
TUPLE {L# L#("L4"), LINESEG LINESEG(RELATION {
TUPLE {Pt Pt(0.0, 0.0)},
TUPLE {Pt Pt(1.0, 0.0)}
}), C# C#("C2")}
}

cheers

Tjerk

These exceptions are definitely a bug, but are essentially unrelated to creating a virtual relvar with a new type. This will be fixed in the next update.

This message is solely to force email notifications to take place on this thread, because I responded whilst email notifications were disabled. I've been doing some server maintenance, and have just re-enabled email notifications. (I hope... )

thanks,

I hope it is useful,

tjerk

The fix for this bug has been released in version 1.0.3.