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 >
