[Mulgara-general] Jena-Mulgara connector
gearon at ieee.org
Sun Jan 13 21:54:49 UTC 2008
On Jan 13, 2008, at 2:03 PM, Seaborne, Andy wrote:
> Andrae Muys wrote:
>> If the problem reusing a blanknode from a query for an insert, as
>> long as you perform the query within the same write-phase you will be
>> fine. Mulgara's understanding of insert/delete is as functions from
>> graphs to graphs, ie: insert :: Triple -> Graph -> Graph.
> Let me just check my understanding: if the app (from iTQL or from the
> remote API) inserts a bnode in an operation, deletes said bnode in a
> second operation, then it's id can be reused even inside the same
> transaction in some later operation.
Let me explain a little more.
All statements in Mulgara are a quad of gNodes (graph nodes). The
fourth is a URI for a graph, and can effectively be ignored in most
gNodes fall into 3 categories. They can be mapped to URIs, they can
be mapped to literals, or they are mapped to nothing. If they are
mapped to nothing, then they represent a blank node. We convert this
into a string (for output) with the format _:nnn (where nnn is the
gNode value). A blank node CANNOT be referred to with this syntax.
It is for output only.
When any resource is "released" (meaning that the last statement using
this resource has been deleted) then the gNode for this resource is
made available again. Any new resource that is allocated will need a
gNode, and the released values are picked up before new ones are
allocated. Note that this gNode can now refer to ANY resource, not
just a blank node!
Also, any gNodes released in the current phase are preferentially re-
allocated first. Without that particular heuristic, a process that
rapidly alternates between inserting and deleting data will create
significant load on the system. So when you say that a bnode's ID
*can* be reused inside the same transaction, I would change that to
say that it is almost certain that the ID *will* be reused.
However, once a newer transaction exists, any released gNodes are not
available again until all old read operations have closed.
> If a trasnaction (i.e. handle to one graph at one point in time) does
> nothing but read operations, then the bnode id is stable.
>> In other words our current semantic is that the result of an update
>> operation on a graph is a new graph, and as such blank-nodes from the
>> pre-update graph are not necessarily the same as the blank-nodes on
>> the post-update graph.
>> So a mulgara instance consists of a sequence of 4-uniform hypergraphs
>> defined as the graphs produced by a sequence of unification and
>> restriction operations starting with an empty graph, and we call the
>> resulting ordinal number of a given graph a phase.
>> This idea of graph immutability (operations don't change the graph,
>> but produce a new one) has formed the basis of our thinking regarding
>> blank-nodes and their interaction with transactions and queries. As
>> a result your blank nodes remain valid for the duration of a
>> transaction, for the moment that means holding the write-lock,
>> however over the next few weeks we will be introducing the ability to
>> obtain read-only transactions which will help alleviate some of your
>> blank-node problems.
> Sounds interesting - any description of the read-only transactions
Andrae has much more to say, but I'll put in my 2c worth (or 2p for
you UK types). Up until now, an answer from any kind of read
operation would always come from the latest version of the database.
This would always be consistent, and is attached to a phase on disk.
However, there was no way to get another read to come from that same
phase, unless you happened to be holding the write lock. The new
transaction code lets you keep hold of a read-only phase to perform
queries on. This lets you get multiple consistent reads without
holding the write-lock. "Consistent" here also means that the ID
associated with a bnode will not change from one read to the next.
> I've already added basic graph pattern support to JenaMulgara so that
> conjunctive triple patterns are sent as a single operation. That
> reduces the bnode effects so that if the app sticks to the Mulgara way
> of doing it, it can ask BGPs.
> Are there plans to support language tags and handle xsd decimals
> they contain a fractional part)?
Language tags: no, but that's more because it's been overlooked. The
XA2 design is still being finalized, so this should be added, if it's
not there already. (Andrae?)
XSD decimals: the full floating point value is stored and retrieved
already. Or are you referring to rational numbers? The answer to
that would be no. Maybe you mean the string version of the decimal
value? (since this often must be approximated in a binary
representation). Again, the answer would be no. Or am I missing the
point in this question?
More information about the Mulgara-general