Back after a long weekend away... For the record, the only reasoning for the below case was that its easiest to implement by the vendors. Here is one of my original examples:
Snip-- 1) Get session and load a contact with name 'Joe' 2) Update the name property from 'Joe' to 'John' 3) Add a new contact 4) Query to get all the contacts and iterate through them 5) See nodes that have an updated state, but don't see any of the newly added nodes! Now you have a strange mix all the previously persisted nodes, nodes that have been updated in the session, but without any of the newly added nodes! Maybe I'm totally missing the point, but I can't fathom *why* the spec would be written this way and really think it should just be one way or the other. ie. Either (ideally) respect the current session state and include ALL session changes in the query results, or, if that is somehow unacceptable/complicated/expensive operation etc., show me the persistent state - just not some funky combination! ---end snip I'm disappointed that there was so much dancing around the issues (by some of the mailing list users) of why this should be considered proper or reasonable, even though its odd, and has results that one would not expect. Defending the spec because its the spec, or saying that its a *big change* or *unfeasible* etc. is unhelpful when a new idea is proposed: -1 to those of you doing so. At least some agreement on whether or not the idea is reasonable or an improvement is needed before shooting suggestions down. David said (re: a proposal for a more strict specification) "I support your idea that from an API users perspective this behaviour could be desirable." Great. David said (re: current spec) "This particular limitation was originally put into the spec because a lot of vendors believe that that it is hard to implement or they cannot implement it at all. " I can perfectly understand why this limitation might exist (many vendors with implementations before JCR came along). However, one of the goals of the spec was to make the API easy for developers, so that has to be considered as well. David said: "As I mentioned I think one could suggest to loosen this contract by leaving the query scope unspecified as a compromise." Yes, would be an OK compromise, and one that I think would be better than the current strange (and mandated) behavior. Ideally, a "particular limitation" would be removed as the spec evolves, but at least it would allow for the newer implementations to provide more sensible behaviors. I would go further and suggest that a default behavior be stated within the spec (either seeing persistent changes or not). I'm going to go write to the 283 committee to update this part of the spec, thanks to everyone for their comments. Best, Mark On 7/23/07, David Nuescheler <[EMAIL PROTECTED]> wrote:
Hi Ivan, Thanks for your summary. > When discussion will cool down I will summarize it and send a feedback to > [EMAIL PROTECTED] very good. > So far it looks like I hit the honey pot, I see a few use-cases from list > members in support of an idea and none against and it bother me. I support your idea that from an API users perspective this behaviour could be desirable. This particular limitation was originally put into the spec because a lot of vendors believe that that it is hard to implement or they cannot implement it at all. So you can consider that the current specification is what most vendors can implement. The section you originally quoted is in the spec on purpose, it is not an oversight. As I mentioned I think one could suggest to loosen this contract by leaving the query scope unspecified as a compromise. Personally, just from my gut feeling I cannot see a lot of support from the vendors for your proposed strict change, but feel free to submit it anyway, and it will certainly be considered. regards, david
-- Best, Mark Waschkowski
