Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [incquery-dev] Viewers refactoring, help needed

I have done a bit more digging in the ComputedSet implementation and came up with a possible fix, but it involves a minor change in the ComputedSet implementation itself (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=414297)

While the patched ComputedSet passes all test cases as defined by the JFace data binding test suite and the small test case that we originally wrote for the issue. It would be nice to test whether the patch fixes the problems in the Viewer framework as well.

If it does, we have several options:
- we can choose to include the patched ComputedSet implementation as an internal class in Viewers. We keep all copyright information and include a disclaimer that the code is copied verbatim from the original class. This is quite ugly.
- we can implement our own observable set (possibly closer to EVM) that is specifically designed with the assumptions that we can make for the viewer framework
- we can decide to use only lists for now, with the expectation that the viewer framework will have to be reimplemented without relying on data binding.

As Zoltán said, we can choose to cut out several levels of observable collections by using the EVM API in the viewer framework and implementing specific observables for items, edges and containment, where the Match->Item/Edge conversion is done by the EVM jobs, instead of data binding converters.

Cheers,
  Ábel Hegedüs

Fault Tolerant Systems Research Group
Department of Measurement and Information Systems
Budapest University of Technology and Economics

On 2013.09.19. 22:34:25, Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxx> wrote:

Sadly, I am not completely surprised that it is not possible to put a ComputedSet inside another; as they try to monitor changes inside the Data binding Realm, and then manually compare the results. We have already observed some cases with forgotten notifications earlier.

What I was originally thinking is to forget about creating a two-level observable collection building and provide a single ComputedSet - it looks really bad, and it could perform quite bad, as it cannot only recalculate a single small ComputedSet but always the other. This approach is even more naive then your implemented solution, however, I have no better idea while relying on the data binding framework.

The only other think I can think about is to extend the data binding layer to create an Observable set directly on the EVM level - however, I am not entirely sure whether that is a useful thing to have outside Viewers (but possibly it is). Some recent functionality created for the transformation API could also help in this regard.

Ábel, what do you think about this approach?

Cheers,
Zoli
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz

Fault Tolerant Systems Research Group
Budapest University of Technology and Economics

On 2013.09.19., at 16:26, Istvan Rath wrote:

> OK I gave this another try today, with a very naive approach: the ComputedSet of ComputedSets.
>
> See http://git.eclipse.org/c/incquery/org.eclipse.incquery.git/tree/plugins/org.eclipse.incquery.viewers.runtime/src/org/eclipse/incquery/viewers/runtime/model/converters/FixedUnionSet.java?id=bf99cb52e800536edd1bc7627996a51528f5c72f
>
> At first, I thought it to be working correctly, but then it turned out that it doesn't :-(
> (Extremely weird behavior, e.g. returns semi-correct results in a debugging session, but completely bogus (empty) results when run normally…)
>
> Any ideas?
>
>
> --
> Istvan RATH, PhD
> Research fellow
> Budapest University of Technology and Economics
> Fault Tolerant Systems Research Group
>
>
>
> On Monday, August 12, 2013 at 7:01 PM, Ujhelyi Zoltán wrote:
>
>> Hi,
>>> HI all,
>>>
>>>> for now, I have sent a message to the Platform forum, as maybe we have missed something (although I am more likely to think it is a bug).
>>>
>>> Are there any news regarding this?
>> Neither in the forum nor in Bugzilla.
>>>
>>>> I am not entirely sure about it, but maybe a more complex computedset implementation could also solve the issue, as we did not experience the same issues with only a single ComputedSet, but maybe I have missed some corner case. (The current implementation is logically cleaner, but maybe this is required).
>>>
>>>
>>> So, if I understand correctly, we should do a workaround by implementing a custom computedset that would emulate the unionset correctly?
>> Yes, I was thinking among this angle.
>>
>> Zoli
>> _______________________________________________
>> incquery-dev mailing list
>> incquery-dev@xxxxxxxxxxx (mailto:incquery-dev@xxxxxxxxxxx)
>> https://dev.eclipse.org/mailman/listinfo/incquery-dev
>>
>>
>
>
> _______________________________________________
> incquery-dev mailing list
> incquery-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/incquery-dev

_______________________________________________
incquery-dev mailing list
incquery-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/incquery-dev

Back to the top