I think we’re both coming at this from different angles hence the disagreement.
Your assumption seems to be that patches are packets, or perhaps messages,
exchanged between parts of the system. Whereas my assumption is that the patch
is similar to a journal and represents a continuous stream of changes with
potentially many packets in your parlance concatenated together. In your
scenario I agree that there is probably no need for reversible at the
transaction level, however in my scenario this could be extremely useful.
Ultimately you probably have to make a call one way or another. You have
actual practical implementation experience with this format so you are probably
better placed to decide what works in the real world. As with the notion of
repeat it is not like a decision made now is a permanent one, you can always
revise the standard in the future provided you include a way to define what
version of the standard a patch conforms to.
Rob
On 20/10/2016 13:50, "Andy Seaborne" <a...@apache.org> wrote:
On 19/10/16 10:51, Rob Vesse wrote:
> On 14/10/2016 17:09, "Andy Seaborne" <a...@apache.org> wrote:
>
> I don't understand what capabilities are enabled by transaction
> granularity if there are multiple transactions in a single patch.
> Concrete examples of where it helps?
>
> However, I've normally been working with one transaction per patch
anyway.
>
> Allowing multiple transaction per patch is for making a collect of
> (semantically) related changes into a unit, by consolidating small
> patches "today's changes " (c.f. git squash).
>
> Leaving the transaction boundaries in gives internal checkpoints, not
> just one big transaction. It also makes the consolidate patch
> decomposable (unlike squash).
>
> Internal checkpoints are useful not just for keeping the transaction
> manageable but also to be able to restart a very large update in case
it
> failed part way through for system reasons (server power cut, user
> reboots laptop by accident, ...) Imagine keeping a DBpedia copy up
to date.
>
> I think the thought is that a producer of A patch can decide whether
> each transaction being recorded should be reversible or not. For
> example if you are a very large dataset to an already large database
> you probably don’t want to slow down the import process by having to
> check whether every triple/quad is already in the database as you
> import it. Therefore you might choose to output a non-reversible
> transaction for performance reasons.
>
> On the other hand if you’re accepting a small change to the data then
> that cost is probably acceptable and you would output a reversible
> transaction.
>
> I am not arguing that you shouldn’t have transaction boundaries, in
> fact I think they are essential, but simply that you may want to be
> to annotate the properties of a transaction Beyond just stating the
> boundaries.
Rob,
I agree the producer needs to have control. What I am asking is why one
patch unit (packet) would have multiple transactions with different
characteristics in it. The properties of patch packet include
reversibility of contents. A patch overall isn't reversible unless each
transaction within it is so there is now an opportunity for errors.
I think unit of patch packet is enough - it is supposed to be a sensible
set of changes to move the dataset from one consistent state to another.
In developing that set of changes, there may have been several
transactions (c.f. git squash). It happens to give a checkpoint effect
on large patches as well.
Analogy that may not help : a "TB/TC" is a database-transaction and a
"patch" is more like a "business transaction".
(The use of "transaction" may not be the best - "action"? but with a
need for "abort" as well as "commit", "transaction"
Andy
