Edit Conflict
Paul Downey
with tiddlers created programatically.
For example I just minted a space only to see the displayMessage
"Error saving ColorPalette: edit conflict".
As a user this puts me into some kind of heightened anxious detective
mode, looking at the timeline, cutting and pasting into another
window, and eventually having to close a window and ignoring the
unsaved changes challenge.
Is there a simple way to get past Edit Conflict? And if so, does
anyone have ideas on how best to present the recovery path to a user
so they don't worry about losing changes?
What I'd really like to do at this point is to save changes as the top
copy ignoring any possible Edit Conflicts.
I guess plugins such as Cecily map and ColorPallete would really just
like to say "really save this tiddler", rather than "update this
tiddler" as the concept of editing doesn't apply.
--
Paul (psd)
http://blog.whatfettle.com
chris...@gmail.com
> It seems like I'm getting Edit Conflicts a *lot* though most often
> with tiddlers created programatically.
There was some conversation about this in IRC yesterday which went a
variety of directions, so I hope FND, Jon and Jeremy will chime in
here too.
There seem to be sort of three angles:
1. It appears to be very easy when programmatically creating tiddlers to
fire off multiple saves of the same tiddler before the previous one has
completed, thus getting the ETag and If-Match headers out of wack. I
believe that this is a problem of us having not gotten the idioms
correct, just yet, for dealing with asynchronous use of tiddlers (but
see also 2, below). Not just in that same TiddlyWiki, but also across
multiple users of the same resources on the server (whether accessed via
space, bag, or some other combo). I tried to write a start about that at
http://tiddlyspace.tiddlyspace.com/#DesigningForAsynchrony but it is
woefully incomplete and needs input from people.
2. There's no clear and easy way to do what you probably want to do,
which is to state up front "I don't care about Edit Conflicts for
this transation". Under the sheets the way to do that is to not send
an If-Match header but handling that is not well exposed (or at
least the exposure thereof is not well understood). I'd hate to see
this become the default as the code that causes Edit Conflict is there on
purpose to prevent lost data when people are collaborating
(knowingly or not) on the same data. That means there are two prongs
here: making it possible to not send an If-Match; making the UI for
recovering from an Edit Conflict when it happening is something of a
good thing.
3. It's very possible there is a bug on the server side that is
causing edit conflicts to happen more often than they should but it
has been impossible to find by inspection. A test case is needed and
I've been unable to create one myself.
> I guess plugins such as Cecily map and ColorPallete would really just
> like to say "really save this tiddler", rather than "update this
> tiddler" as the concept of editing doesn't apply.
That does seem to be the case.
I also think that things like the Cecily map probably don't need to
be updated back to the server every time there is a change. Until the
end of _your_ session the map is only state for _your_ session, it
doesn't need to go back to the server, does it? It could be sort of
thread local in a way, until you choose otherwise, but it is operating as a
global.
--
Chris Dent http://burningchrome.com/
[...]
rakugo
saved has changed significantly.
The RandomColorPalette really shouldn't cause any edit conflicts
unless the space is shared. Currently it only saves on the server
after a delay of a couple of seconds. Thus it doesn't "clobber" the
server with puts.
All it currently does is run TiddlyWiki's saveTiddler function
followed by an autoSaveChanges(). Is this not correct?
It appears very easy now however to cause an edit conflict.
I just got one now although am not sure what is useful for debugging
this issue.
Maybe we can address it on irc #tiddlyweb?
Jon
On 24 Sep, 10:11, chris.d...@gmail.com wrote:
> On Thu, 23 Sep 2010, Paul Downey wrote:
> > It seems like I'm getting Edit Conflicts a *lot* though most often
> > with tiddlers created programatically.
>
> There was some conversation about this in IRC yesterday which went a
> variety of directions, so I hope FND, Jon and Jeremy will chime in
> here too.
>
> There seem to be sort of three angles:
>
> 1. It appears to be very easy when programmatically creating tiddlers to
> fire off multiple saves of the same tiddler before the previous one has
> completed, thus getting the ETag and If-Match headers out of wack. I
> believe that this is a problem of us having not gotten the idioms
> correct, just yet, for dealing with asynchronous use of tiddlers (but
> see also 2, below). Not just in that same TiddlyWiki, but also across
> multiple users of the same resources on the server (whether accessed via
FND
> saved has changed significantly.
I do not recall any such change. I'm also having trouble reproducing
these issues (application-specific issues aside).
> All it currently does is run TiddlyWiki's saveTiddler function
> followed by an autoSaveChanges(). Is this not correct?
It should be. Obviously fields and such matter, so it's hard to say
without a proper test case.
-- F.
PMario
What I did for one of my projects, that needed to run at tiddlyspace,
coming from a file tw.
added:
var fields={}; // no metadata at the moment
fields = merge({}, config.defaultCustomFields);
before
store.saveTiddler(projName,projName,text,who,when,tags,fields);
works nice. No edit conflicts. Since saveChanges is done manually.
=========
But now i have the following situation:
1)
plugin-space is included into
work-space
2)
plugin-space contains a lot of templates, that need to be cloned into
work-space if changed.
I took the following from TiddlySpaceCloneCommand for cloning a
tiddler.
tiddler.fields["server.workspace"] = "bags/%0_private".
format([tiddlyspace.currentSpace.name]);
delete fields["server.permissions"]; // no edit window is displayed.
delete tiddler.fields["server.page.revision"];
delete tiddler.fields["server.title"];
delete tiddler.fields["server.etag"];
store.saveTiddler()
saveChanges is done manually.
====
All works fine, but only once. Because with the second save, the
tiddler is part of the local space and saving again rises an edit
confilict.
====
My question now is:
What exactly causes the server to say edit conflict because of
precondition faild.
What is the etag for and how is it managed at the server.
I know, that deleting the etag, does cause the error. So what needs to
be done that I can programmatically save a tiddler two times.
regards
mario
rakugo
conflicts all together.
What might be better is making use of the following plugin
(experimental):
http://experiment.tiddlyspace.com/#EditConflictHandlerPlugin
This will let you resolve edit conflicts more gracefully (ie. not lose
a previous save).
Please let me know how you get on..
Jon
PMario
What does server.page.revision = false; do?
I have seen the plugin allready and included it. Reading the source, I
can imagine what it should do. There is an interface, which needs
manual interaction. I don't want manual interaction.
Today I did some more changes at the source. Now there isn't any
confilict anymore. Needs some more investigation. Or have there been
changes at the server yesterday or today?
-m
On Oct 26, 5:21 pm, rakugo <jdlrob...@gmail.com> wrote:
> You should set the server.page.revision field to false to preventedit
> conflicts all together.
>
> What might be better is making use of the following plugin
> (experimental):http://experiment.tiddlyspace.com/#EditConflictHandlerPlugin
>
>
> Please let me know how you get on..
> Jon
>
> On 26 Oct, 15:40, PMario <pmari...@gmail.com> wrote:
>
> > Hi folks,
>
> > What I did for one of my projects, that needed to run at tiddlyspace,
> > coming from a file tw.
>
> > added:
> > var fields={}; // no metadata at the moment
> > fields = merge({}, config.defaultCustomFields);
>
> > before
> > store.saveTiddler(projName,projName,text,who,when,tags,fields);
>
> > =========
> > But now i have the following situation:
>
> > 1)
> > plugin-space is included into
> > work-space
>
> > 2)
> > plugin-space contains a lot of templates, that need to be cloned into
> > work-space if changed.
>
> > I took the following from TiddlySpaceCloneCommand for cloning a
> > tiddler.
>
> > tiddler.fields["server.workspace"] = "bags/%0_private".
> > format([tiddlyspace.currentSpace.name]);
>
> > delete tiddler.fields["server.title"];
> > delete tiddler.fields["server.etag"];
>
> > store.saveTiddler()
> > saveChanges is done manually.
>
> > ====
> > All works fine, but only once. Because with the second save, the
> > tiddler is part of the local space and saving again rises anedit
> > confilict.
>
> > ====
>
> > My question now is:
FND
It enables "clobbering":
http://trac.tiddlywiki.org/changeset/12105
Note that this convention will likely change with the upcoming adaptor
rewrite - I'm just not sure yet what a more appropriate flag might be.
-- F.
chris...@gmail.com
I know you've had some satisfactory answers to this already, but I
thought I'd provide some background on what is going on.
> My question now is:
> What exactly causes the server to say edit conflict because of
> precondition faild.
When you do a tiddler PUT the server looks for a header called
'If-Match'. If it is there it will contain what is assumed to be the
ETag of the tiddler. This is a uniquely[1] identifying string for this
revision of this tiddler
That ETag is generated by the some values inherent to the tiddler.
The server generates an ETag for the tiddler it is holding in its
storage. If the ETag in the If-Match header is not the same as the
one from the store then while you had your tiddler out and were
making edits, somebody else made a change.
That is: There has been an edit conflict: You and someone else
edited the same tiddler at near the same time and the someone else
got their changes in first. The ETag (when used in the PUT
context[2]) makes it possible for you to be made aware of this
and do something about it if you want.
You can get more technical details from:
"Detecting the Lost Update Problem Using Unreserved Checkout"
http://www.w3.org/1999/04/Editing/
You'll have noticed a few things:
* This doesn't always work as well as we would like. There are
situations where edit conflicts are happening that don't seem
quite right. This is being worked on and fixed.
* If you don't want edit conflict protection the If-Match header is
not sent. In that case, you will always clobber. Setting (at the
moment) 'server.page.revision' to 'false' (the string "false")
makes it so the If-Match header is not sent.
* The UI for dealing with edit conflicts is non-existent. There are
a few different ideas on how to make it better, including some
writing that fnd, jon and I have been doing:
http://cdent.tiddlyspace.com/#EditConflicts
> What is the etag for and how is it managed at the server.
Specifically the ETag is a thing that shows up in the HTTP header
identifying the resource named by the URI. In TiddlyWebWiki this is
overridden a bit to add a server.etag field to tiddler in the wiki
to make updating them a bit safer.
[1] Unique in the domain of this tiddlyspace server, not the
universe.
[2] In the GET context an ETag is used for cache validation. When
a GET is sent an "If-None-Match" header is sent, containing the ETag
of the tiddler in cache. If the server-side ETag is the same, the
server responds with a 304, signalling that the tiddler in cache can
be used, saving bandwidth.
PMario
Now all questions are answered.
-m