Hello,
> > And here is a real-life use cases.
I think there is an obvious real-life use case that does need the transient changes to be
visible in the QueryResult: We are using jackrabbit to expose a facetted navigation, so regardless
the hierarchical structure in which nodes are stored in jackrabbit, we offer a facetted navigation
view for users in which they define the way they want to navigate (~search) through the content
theirselves.
Now, if somebody changes a property value of a facet (ie, a drag drop move of a document in
a facet view is changing a facet value), this change stays in his transient session. Since
the facetted view is a view totally based on queries, this means that the change is only visible
*after* a session save / commit. To automatically save/commit any change of a user when it
affects a facet value does seem inferior to me: I haven't sorted all out yet, but I suppose
indexing is done by a (background) queue running every X sec...But, I need the index updated
instantly, because can't have the client waiting for a background queue to finish.
IMO, facetted navigation is becoming more and more popular, customers are getting used to
this "new" way of browsing, and it seems to me a very real-life use case where the current
implementation is less useable. Obviously a "QUERY_TRANSIENT_CHANGE_VISIBILITY" would be great
IMO. OTH, I do think that it is quite a bit harder to implement this transient visibility.
Ard
> >
> > Imagine you are creating/editing a document where you need
> to add a contact
> > and happened that contact is not there so you add the
> contact, but you can't
> > save it yet because you are creating/editing a document,
> but you need to
> > look-up this contact to add to the document, so you run a query ...
>
> Would you design a relational database client that leaves a
> transaction open like that for extended amounts of time? I don't think
> that's best practice.
>
> In fact I think JCR is better suited for managing such long-lived
> draft content for the very reason that the transient changes are
> clearly separate from the persistent storage and can be handled
> entirely on the client side of a client-server model. A relational
> database typically (at least) write-locks all rows that are being
> modified in a transaction.
>
> BR,
>
> Jukka Zitting
>
|