Mailing List Archive: Bricolage: devel

Stale Document Session

Index | Next | Previous | View Threaded

david at kineticode

Aug 17, 2009, 11:23 AM

Post #1 of 10 (2329 views)
Permalink

Stale Document Session

Greetings Fellow Bricoleurs,

I started to look at [this patch][] from Greg to figure out just what
it fixes. And I realized that the problem comes about if a user edits
a story, and then leaves the story by some means other than the button
bar at the bottom of the story profile. Maybe he clicked "Save and
Stay" and then went directly to My Workspace, instead of clicking
"Save" or "Cancel". The result is that the story is not properly
cleared from the session. If he checks in the story with the stale
session still in place, it can (and clearly does) wreak havoc.

[this patch]: http://github.com/bricoleurs/bricolage/commit/7771128a6316e42b31230db345f4602e8aeb5662

The problem with the patch, however, is that it's either too broad an
application, or too specific, depending on how you look at it. It's
too broad in the sense that it might be a completely different story
in the session than the one that's being checked in. So no matter
what's checked in, the session is cleared. If there were unsaved
changes in the session copy and the user goes back into the story,
those changes will be lost.

On the other hand, perhaps a user who leaves the story profile
*should* lose any unsaved changes. After all, if they want to save
them, that's what the "Save" and "Save and Stay" buttons are for --
there are no guarantees documented anywhere that I'm aware of saying
that unsaved changes will persist. Indeed, it's already the case that
if you leave a story profile without saving changes and then edit a
different story, the changes to the first story will be lost, because
the second story replaces it in the session. It is in this sense that
the clearing of the cache in the desk checkin is too specific: we
should potentially clear the story cache as soon as the user leaves a
story profile, not just when he tries to check in a story.

So what to do? I suspect that there are other places where a stale
cache of a story causes problems, so it behooves us, I think, to
generalize the solution to remove the session copy of a story anytime
the user leave the story profile. I think that the way to do so is to
add a PreCallback that checks every single request to the server, and
if the profile key is not in the request but is in the session, we
remove it from the session.

Comments?

--David

D-Beaudet at NGA

Aug 17, 2009, 1:07 PM

Post #2 of 10 (2236 views)
Permalink

RE: Stale Document Session [In reply to]

Maybe someone could do some performance testing to assess whether the UI
cache is even necessary?

> -----Original Message-----
> From: David E. Wheeler [mailto:david [at] kineticode]
> Sent: Monday, August 17, 2009 2:24 PM
> To: Bricolage Developers
> Subject: Stale Document Session
>
> Greetings Fellow Bricoleurs,
>
> I started to look at [this patch][] from Greg to figure out just what
> it fixes. And I realized that the problem comes about if a user edits
> a story, and then leaves the story by some means other than the button
> bar at the bottom of the story profile. Maybe he clicked "Save and
> Stay" and then went directly to My Workspace, instead of clicking
> "Save" or "Cancel". The result is that the story is not properly
> cleared from the session. If he checks in the story with the stale
> session still in place, it can (and clearly does) wreak havoc.
>
> [this patch]:
>
http://github.com/bricoleurs/bricolage/commit/7771128a6316e42b31230db345
f4
> 602e8aeb5662
>
> The problem with the patch, however, is that it's either too broad an
> application, or too specific, depending on how you look at it. It's
> too broad in the sense that it might be a completely different story
> in the session than the one that's being checked in. So no matter
> what's checked in, the session is cleared. If there were unsaved
> changes in the session copy and the user goes back into the story,
> those changes will be lost.
>
> On the other hand, perhaps a user who leaves the story profile
> *should* lose any unsaved changes. After all, if they want to save
> them, that's what the "Save" and "Save and Stay" buttons are for --
> there are no guarantees documented anywhere that I'm aware of saying
> that unsaved changes will persist. Indeed, it's already the case that
> if you leave a story profile without saving changes and then edit a
> different story, the changes to the first story will be lost, because
> the second story replaces it in the session. It is in this sense that
> the clearing of the cache in the desk checkin is too specific: we
> should potentially clear the story cache as soon as the user leaves a
> story profile, not just when he tries to check in a story.
>
> So what to do? I suspect that there are other places where a stale
> cache of a story causes problems, so it behooves us, I think, to
> generalize the solution to remove the session copy of a story anytime
> the user leave the story profile. I think that the way to do so is to
> add a PreCallback that checks every single request to the server, and
> if the profile key is not in the request but is in the session, we
> remove it from the session.
>
> Comments?
>
> --David

david at kineticode

Aug 17, 2009, 1:10 PM

Post #3 of 10 (2234 views)
Permalink

Re: Stale Document Session [In reply to]

On Aug 17, 2009, at 1:07 PM, Beaudet, David wrote:

> Maybe someone could do some performance testing to assess whether
> the UI
> cache is even necessary?

Oh, it's necessary. They way in which subelements is loaded is pretty
inefficient, with a query for every layer of subelement. It's awful.
Caching it is the only sane thing to do.

If the querying could be made more efficient, we could get rid of the
caching. I'd like this, but it'd be a metric fuckton of work, and has
no sex appeal.

Best,

David

phillip at communitybandwidth

Aug 17, 2009, 1:56 PM

Post #4 of 10 (2230 views)
Permalink

Re: Stale Document Session [In reply to]

On 17-Aug-09, at 3:23 PM, David E. Wheeler wrote:

> On the other hand, perhaps a user who leaves the story profile
> *should* lose any unsaved changes. After all, if they want to save
> them, that's what the "Save" and "Save and Stay" buttons are for --
> there are no guarantees documented anywhere that I'm aware of saying
> that unsaved changes will persist.

What about using an AJAX auto-save type thingamabob?

--
Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
www.communitybandwidth.ca // www.phillipadsmith.com

Attachments:

smime.p7s (2.38 KB)

bret at pectopah

Aug 17, 2009, 2:07 PM

Post #5 of 10 (2236 views)
Permalink

Re: Stale Document Session [In reply to]

Hi everybody,

> > On the other hand, perhaps a user who leaves the story profile
> > *should* lose any unsaved changes. After all, if they want to save
> > them, that's what the "Save" and "Save and Stay" buttons are for --
> > there are no guarantees documented anywhere that I'm aware of saying
> > that unsaved changes will persist.

I agree. It makes sense to me that one field will remember its contents
when you add another field, so the caching while you're on the story
profile is good and reasonable.

But I think you *should* lose unsaved changes if you don't deliberately
Save/Save & Stay. Any other behaviour is just kind of counter-intuitive.

--
Bret Dawson
Producer
Pectopah Productions Inc.
(416) 895-7635
bret [at] pectopah
www.pectopah.com

david at kineticode

Aug 17, 2009, 3:02 PM

Post #6 of 10 (2236 views)
Permalink

Re: Stale Document Session [In reply to]

On Aug 17, 2009, at 1:56 PM, Phillip Smith wrote:

>> On the other hand, perhaps a user who leaves the story profile
>> *should* lose any unsaved changes. After all, if they want to save
>> them, that's what the "Save" and "Save and Stay" buttons are for --
>> there are no guarantees documented anywhere that I'm aware of
>> saying that unsaved changes will persist.
>
> What about using an AJAX auto-save type thingamabob?

That's of no help once the user has left the profile.

David

phillip at communitybandwidth

Aug 17, 2009, 3:07 PM

Post #7 of 10 (2233 views)
Permalink

Re: Stale Document Session [In reply to]

On 17-Aug-09, at 7:02 PM, David E. Wheeler wrote:

> On Aug 17, 2009, at 1:56 PM, Phillip Smith wrote:
>
>>> On the other hand, perhaps a user who leaves the story profile
>>> *should* lose any unsaved changes. After all, if they want to save
>>> them, that's what the "Save" and "Save and Stay" buttons are for
>>> -- there are no guarantees documented anywhere that I'm aware of
>>> saying that unsaved changes will persist.
>>
>> What about using an AJAX auto-save type thingamabob?
>
> That's of no help once the user has left the profile.

Agreed. But it would help if s/he accidentally left the profile (and
it had saved a moment earlier).

--
Phillip Smith // Simplifier of Technology // COMMUNITY BANDWIDTH
www.communitybandwidth.ca // www.phillipadsmith.com

Attachments:

smime.p7s (2.38 KB)

david at kineticode

Aug 17, 2009, 3:08 PM

Post #8 of 10 (2232 views)
Permalink

Re: Stale Document Session [In reply to]

On Aug 17, 2009, at 2:07 PM, Bret Dawson wrote:

> I agree. It makes sense to me that one field will remember its
> contents
> when you add another field, so the caching while you're on the story
> profile is good and reasonable.
>
> But I think you *should* lose unsaved changes if you don't
> deliberately
> Save/Save & Stay. Any other behaviour is just kind of counter-
> intuitive.

Well, it turned out that that approach was more work than it was
worth. I ended up modifying what Greg had committed to check the asset
ID in the session before it deleted the session. I also added code to
clear the session in the `checkout()` callback from the desk, as
that's where the underlying problem was in this case (if you're
checking out a story, there's no need to fetch anything from cache, it
*will* have expired). So I think that this catches the major cases.
I'm looking into integrating it into master now, where the callbacks
have changed a fair bit.

Best,

David

david at kineticode

Aug 17, 2009, 3:08 PM

Post #9 of 10 (2232 views)
Permalink

Re: Stale Document Session [In reply to]

On Aug 17, 2009, at 3:07 PM, Phillip Smith wrote:

> Agreed. But it would help if s/he accidentally left the profile (and
> it had saved a moment earlier).

I don't really care about that case. Bricolage has no autosave, and
never has. That sort of shit gets broken when you go offline, anyway.
Too fragile, and too inconsistent with the rest of Bricolage: nothing
should be saved unless you click "Save," period.

David

david at kineticode

Aug 17, 2009, 3:09 PM

Post #10 of 10 (2241 views)
Permalink

Re: Stale Document Session [In reply to]

On Aug 17, 2009, at 2:07 PM, Bret Dawson wrote:

> I agree. It makes sense to me that one field will remember its
> contents
> when you add another field, so the caching while you're on the story
> profile is good and reasonable.

Oh, and BTW, many thanks for including the reproducible case in that
ticket, Bret. That was a *huge* help.

David

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads