Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [viatra-dev] Transformation API 
Ok, I think, I got it.

This way we are losing more than simple switching between transactional and non-transactional (currently, this requires a change of a single instance variable), as we would not be able to infer/log model manipulations in an easy to handle way (as of now, mostly required for research purposes).

On the other hand, we could ask the developer to fill its transformation code into transaction methods, but it does not seem easy to write to me as well. Additionally, as we do not know about the specific operations executed, we have to rely on RecordingCommands for transaction support (that seems to be slow based on our previous experience).

So, at first glance, I do not think, it would solve our problems, but I will sleep over it.

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.29., at 22:20, Istvan Rath <rath@xxxxxxxxxx> wrote:

> IIRC you said that plain Xtend style manipulation code is not OK b/c it is not transparent to running with or without transaction management.  
> 
> So the solution was to wrap all model manipulation into calls to our API, which would then hide what is going on under the hood.
> 
> I am suggesting an alternative, that is to "expose" the transaction boundaries on the API, but allow just about any style of writing model manipulation (be it Xtend or plain old Java).  
> 
> --
> Istvan RATH, PhD
> Research fellow
> Budapest University of Technology and Economics
> Fault Tolerant Systems Research Group
> 
> 
> 
> On Sunday, September 29, 2013 at 10:15 PM, Ujhelyi Zoltán wrote:
> 
>> I am not sure if I understood correctly your idea, but I guess the API design for the commands were motivated by an entirely other case: supporting model manipulations both with and without a (Transactional)EditingDomain. For this reason, a simple set of commands were defined (create, set, add and remove) that can be implemented multiple ways.
>> 
>> The "convenience methods" were motivated by the fact that the defined API is not too easy to write, as we have to manage _both_ the Java model implementation and the metamodel, as the types are not exactly the same.
>> 
>> About packaging operations, because of the dual implementation requirement, I do not believe normal Xtend model manipulation operations would be sufficient, but is clearly possible to group our model manipulation commands into more complex operations by defining extra methods; however, I do not see a large number of higher-level, _generic_ operations missing (of course I am open to see some of them, and they are easy to add). On the other hand, I believe, such chaining is very useful for metamodel-specific implementations (and are of course possible).
>> 
>> If I misunderstood your idea, I would like some clarification.
>> 
>> 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.29., at 22:00, Istvan Rath <rath@xxxxxxxxxx (mailto:rath@xxxxxxxxxx)> wrote:
>> 
>>> OK, I think I get it now.  
>>> 
>>> The other idea I had in mind was to provide an API shorthand for "packaging" several simple (pure Xtend) manipulation operations into a single "command". AFAIK this is the main reason why we want to create "convenience methods" in the first place right? What if we turn the whole thing on its head?  
>>> 
>>> --
>>> Istvan RATH, PhD
>>> Research fellow
>>> Budapest University of Technology and Economics
>>> Fault Tolerant Systems Research Group
>>> 
>>> 
>>> 
>>> On Sunday, September 29, 2013 at 9:53 PM, Ujhelyi Zoltán wrote:
>>> 
>>>> Hi,
>>>> 
>>>> the state_Name is the EMF Reflective API literal (Xtend shorthand for *Package.getState_Name() ), while basic is the Object we are setting, so the code is not bogus (at least not in an easily understandable way).
>>>> 
>>>> However, this code is not the easiest thing to write manually (at least it was not for me), that's why an alternative like Gábor suggested would be nice (but sadly, I believe is not feasible for single-value features).
>>>> 
>>>> 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.29., at 21:49, Istvan Rath <rath@xxxxxxxxxx (mailto:rath@xxxxxxxxxx)> wrote:
>>>> 
>>>>> So the line
>>>>> 
>>>>> basic.set(state_Name, p.name (http://p.name))///name = p.name (http://p.name)
>>>>> 
>>>>> from http://wiki.eclipse.org/VIATRA2/EMF/Transformation_API#Defining_rules.2C_rulegroups is bogus?
>>>>> 
>>>>> 
>>>>> Why don't we require to use the EMF reflective API in this case? I.e. by passing the appropriate literal from the EPackage?  
>>>>> 
>>>>> --
>>>>> Istvan RATH, PhD
>>>>> Research fellow
>>>>> Budapest University of Technology and Economics
>>>>> Fault Tolerant Systems Research Group
>>>>> 
>>>>> 
>>>>> 
>>>>> On Sunday, September 29, 2013 at 9:41 PM, Ujhelyi Zoltán wrote:
>>>>> 
>>>>>> The problem is that I cannot find any implementation behind the interface, that works, as the method.name (http://method.name) would return a string without any metainformation, e.g. the corresponding EStructuralFeature. Without knowing the feature (even by knowing the defining object and the Java type) it is not possible to change to original reference.
>>>>>> 
>>>>>> This issue does not appear in case of lists, as EMF always returns modifiable lists.
>>>>>> 
>>>>>> 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.29., at 21:36, Istvan Rath <rath@xxxxxxxxxx (mailto:rath@xxxxxxxxxx)> wrote:
>>>>>> 
>>>>>>>> 
>>>>>>>> Gábor suggested to have convenience methods that handle ELists findable from the EMF API, e.g.:
>>>>>>>> * method.add(method.parameters, newParameter)
>>>>>>>> 
>>>>>>>> This approach works well for multi-valued references (even better than my EMF-reflective implementation), however, for single-value references or attribute I see no way of implementing an API like this, e.g.:
>>>>>>>> * method.set(method.name (http://method.name), "main")
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> What's wrong with this? I don't think it looks awkward.
>>>>>>> 
>>>>>>> --
>>>>>>> Istvan RATH, PhD
>>>>>>> Research fellow
>>>>>>> Budapest University of Technology and Economics
>>>>>>> Fault Tolerant Systems Research Group
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> viatra-dev mailing list
>>>>>>> viatra-dev@xxxxxxxxxxx (mailto:viatra-dev@xxxxxxxxxxx)
>>>>>>> https://dev.eclipse.org/mailman/listinfo/viatra-dev
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> viatra-dev mailing list
>>>>>> viatra-dev@xxxxxxxxxxx (mailto:viatra-dev@xxxxxxxxxxx)
>>>>>> https://dev.eclipse.org/mailman/listinfo/viatra-dev
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> viatra-dev mailing list
>>>>> viatra-dev@xxxxxxxxxxx (mailto:viatra-dev@xxxxxxxxxxx)
>>>>> https://dev.eclipse.org/mailman/listinfo/viatra-dev
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> viatra-dev mailing list
>>>> viatra-dev@xxxxxxxxxxx (mailto:viatra-dev@xxxxxxxxxxx)
>>>> https://dev.eclipse.org/mailman/listinfo/viatra-dev
>>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> viatra-dev mailing list
>>> viatra-dev@xxxxxxxxxxx (mailto:viatra-dev@xxxxxxxxxxx)
>>> https://dev.eclipse.org/mailman/listinfo/viatra-dev
>>> 
>> 
>> 
>> _______________________________________________
>> viatra-dev mailing list
>> viatra-dev@xxxxxxxxxxx (mailto:viatra-dev@xxxxxxxxxxx)
>> https://dev.eclipse.org/mailman/listinfo/viatra-dev
>> 
>> 
> 
> 
> _______________________________________________
> viatra-dev mailing list
> viatra-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/viatra-dev

Back to the top