However there may be multiple ways to check whether a row fits for a certain type:
- It may be a row of the exact same type, created with the same type object.
- It may be a row of another type but one with the exact same definition.
- It may be a row of another type that has the same number of fields and field types but different field names. The field names (and everything else in Triceps) are case-sensitive.
$rt1->same($rt2) $rt1->equals($rt2) $rt1->match($rt2)
The comparisons are hierarchical: if two type references are the same, they would also be equal and matching; two equal types are also matching.
Most of objects would accept the rows of any matching type (this may change or become adjustable in the future). However if the rows are not of the same type, this check involves a performance penalty. If the types are the same, the comparison is limited to comparing the pointers. But if not, then the whole type definition has to be compared. So every time a row of a different type is passed, it would involve the overhead of type comparison.
For example:
my @schema = ( a => "int32", b => "string" ); my $rt1 = Triceps::RowType->new(@schema) or die "$!"; # $rt2 is equal to $rt1: same field names and field types my $rt2 = Triceps::RowType->new(@schema) or die "$!"; # $rt3 matches $rt1 and $rt2: same field types but different names my $rt3 = Triceps::RowType->new( A => "int32", B => "string" ) or die "$!"; my $lab = $unit->makeDummyLabel($rt1, "lab") or die "$!"; # same type, efficient my $rop1 = $lab->makeRowop(&Triceps::OP_INSERT, $rt1->makeRowArray(1, "x")) or die "$!"; # different row type, involves a comparison overhead my $rop2 = $lab->makeRowop(&Triceps::OP_INSERT, $rt2->makeRowArray(1, "x")) or die "$!"; # different row type, involves a comparison overhead my $rop3 = $lab->makeRowop(&Triceps::OP_INSERT, $rt3->makeRowArray(1, "x")) or die "$!";
A dummy label used here is a label that does nothing (its usefulness will be explained later).
No comments:
Post a Comment