GraphUtil.OldStyle

[Holger Knublauch <ho...@knublauch.com>]

While upgrading to the latest snapshots I noticed some subtle 
differences in behavior, related to the deprecation of BulkUpdateHandler 
and the corresponding usage of the GraphUtil.add/delete methods. We do 
have a very complicating chain of event listeners, delegating graphs 
etc, and possibly the change has broken some assumptions that were 
previously true. It works as before when I hack GraphUtil.OldStyle and 
set the flag to false, to bypass the logic related to GraphWithPerform.

Long story, short question: can anybody explain why the 
GraphUtil.OldStyle flag has been introduced? Is the goal to switch the 
old style off in the future? Could it be exposed as a public (non-final) 
field so that we can set it to false for our use cases?

Thanks,
Holger

Re: GraphUtil.OldStyle

[Holger Knublauch <ho...@knublauch.com>]

On 8/28/2013 18:47, Andy Seaborne wrote:
> On 28/08/13 06:34, Holger Knublauch wrote:
>> While upgrading to the latest snapshots I noticed some subtle
>> differences in behavior, related to the deprecation of BulkUpdateHandler
>> and the corresponding usage of the GraphUtil.add/delete methods. We do
>> have a very complicating chain of event listeners, delegating graphs
>> etc, and possibly the change has broken some assumptions that were
>> previously true. It works as before when I hack GraphUtil.OldStyle and
>> set the flag to false, to bypass the logic related to GraphWithPerform.
>>
>> Long story, short question: can anybody explain why the
>> GraphUtil.OldStyle flag has been introduced? Is the goal to switch the
>> old style off in the future? Could it be exposed as a public (non-final)
>> field so that we can set it to false for our use cases?
>>
>> Thanks,
>> Holger
>>
>
> Holger,
>
> Too little information.  What differences do you notice?

It's too early for me to even understand this - this is a very 
complicating part of our system. I was trying to collect some background 
so that I know where to look, and where to spend the next few days 
debugging ;(

>
> When true, the fixed setting, GraphUtil.OldStyle is supposed to give 
> the previous semantics (and it makes the jena core test suite pass - 
> else you get 144 test failures).

The test failures are fortunately all about the events only, and this 
feels like a rather irrelevant aspect of the semantics - consuming code 
should be able to handle any combination of add/iterator/list events.

Anyway, I can create my own version of Jena for now which sets this to 
false so that our stuff behaves as before, while I investigate further. 
It is quite plausible that the bug is in our code...

Thanks
Holger

Re: GraphUtil.OldStyle

[Andy Seaborne <an...@apache.org>]

On 28/08/13 06:34, Holger Knublauch wrote:
> While upgrading to the latest snapshots I noticed some subtle
> differences in behavior, related to the deprecation of BulkUpdateHandler
> and the corresponding usage of the GraphUtil.add/delete methods. We do
> have a very complicating chain of event listeners, delegating graphs
> etc, and possibly the change has broken some assumptions that were
> previously true. It works as before when I hack GraphUtil.OldStyle and
> set the flag to false, to bypass the logic related to GraphWithPerform.
>
> Long story, short question: can anybody explain why the
> GraphUtil.OldStyle flag has been introduced? Is the goal to switch the
> old style off in the future? Could it be exposed as a public (non-final)
> field so that we can set it to false for our use cases?
>
> Thanks,
> Holger
>

Holger,

Too little information.  What differences do you notice?

When true, the fixed setting, GraphUtil.OldStyle is supposed to give the 
previous semantics (and it makes the jena core test suite pass - else 
you get 144 test failures).

	Andy