{5} Assigned, Active Tickets by Owner (Full Description) (5 matches)
List tickets assigned, group by ticket owner. This report demonstrates the use of full-row display.
andrae
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #81 | Blank Node Assignment in Inserts inconsistent with autocommit | Mulgara | defect | 02/27/08 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
It appears that the binding of variables to blank nodes when inserting statements behaves differently depending on whether autocommit is turned on for the session. If I have autocommit turned on and execute the following iTQL commands: create <rmi://localhost/server1#test>;
insert <test:subj> <test:pred> $x $x <test:value> 'o1'
into <rmi://localhost/server1#test> ;
insert <test:subj> <test:pred> $x $x <test:value> 'o2'
into <rmi://localhost/server1#test> ;
select $s $p $o from <rmi://localhost/server1#test> where $s $p $o;
Then I see that the variable "x" is bound to different blank nodes in each of the two insertions, and the resulting model has 4 statements. This is the behavior (behaviour?) that I would expect. However, when I turn autocommit off prior to the first insertion, and turn it back on after the second insertion, then I see that the variable "x" is bound to the *same* blank node in each of the insertions, resulting in 3 total statements in the model, which came as a bit of a surprise to me. Is this the expected behavior in that situation? |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #15 | Product of Sum form has very poor performance. | Mulgara | None | defect | 09/05/06 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
OrderedAppend currently assumes that all it's operands share a common ordering. This is currently guarenteed by TuplesOperations.append(), but the use of calls to project() on all operands not matching the first's variable list. This has signifigant performance ramifications as the desired ordering is unknown until any parent-join is optimised.
Without the projections currently done by TuplesOperations.append(), we need new logic in OrderedAppend to handle mapping variables to operands columns. This is not a problem unless there the disjunction is subject to a join containing a left-bound prefix including mismatched variables. Consider the following tuple expressions: A[$z] ^ B( C[$z $y] v D[$y $z] ) Note: A[] will provide $z prefix to B[]. B[] currently passes this on blindly to C[] and D[]. This will bind $z for $y in D[], leading to an incorrect result. Currently the non-union compatible Fixing this will require either reordering D[], or filtering it; deciding between them is a performance optimisation issue. A[$y $z] ^ B(C[$y] v D[$z]) Note: Here there is a full prefix provided by A[] to B[]. The prefix needs to be decomposed for C[] and D[] This is a case of non-union compatible disjunction, and will probably result in UNBOUND's. Cases where this is probably a problem: non-symmetric sum-of-products (ie. {$a <foo> $b ^ $b <bar> $c in <m1>} v {$b <bar> $c ^ $a <foo> $b in <m2>} ) Note: this is one of the key areas of concern. Differences between models can cause join-optimisation to generate a different ordering; This interferes with attempts to improve SOP performance which is required to support efficient views. symmetric disjunctions: (ie. $s <foo> $o v $o <bar> $s). - uncommon. non-union compatible disjunction (ie. $s <name> $name v $s <email> $email) Note: this query is better phrased as a subquery anyway. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #86 | Clean up XSD Resolver so it becomes suitable demo-resolver | Mulgara | enhancement | 03/16/08 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The XSD-Resolver is currently in a very poor state of repair. The Resolver Interface also desperately requires detailed documentation, and this really requires an exemplar resolver. Clean up the XSD-Resolver so that it can be used as an example of how to write a resolver. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #91 | Refactor OperationContext to provide access to the Operational-Subset of Session. | Mulgara | enhancement | 03/25/08 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Currently we have multiple Operation classes performing their own explicit insertion routines. This duplication should be refactored into ModifyModelOperation?, and all other operations that require insertion functionality should do so via calls to Session::insert() and Session::delete(). |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
pag
| Ticket | Summary | Component | Milestone | Type | Created | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #61 | SPARQL Language | Mulgara | None | enhancement | 05/04/07 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Implement the SPARQL language as an adjunct to TQL:
http://www.w3.org/TR/rdf-sparql-query/ Dependent on MGR-59 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
