[gme-users] Nested transactions

[Kevin Smyth]

Another options to consider is undo support, but you would need to keep track 
of how many transactions you'd like to undo.

Kevin

-----Original Message-----
From: gme-users-bounces at list.isis.vanderbilt.edu 
[mailto:gme-users-bounces at list.isis.vanderbilt.edu] On Behalf Of James H. Hill
Sent: Thursday, August 05, 2010 9:23 PM
To: gme-users
Subject: Re: [gme-users] Nested transactions

Hi Peter,

On 8/5/10 10:27 AM, Peter Volgyesi wrote:
> Hi James,
>
> I wonder what do you gain by having a "root transaction". In your
> interpreter you can have fine grained transaction logic (I guess we
> call this "custom transactions" in the interpreter wizard and/or in
> the componentconfig.h file). So, your interpreter can commit changes
> any time to trigger the add-ons (and GUI), but why do you need an all
> encompassing transaction in this case ?

The reason is because I am creating a GUI for entering input the values
of complex types, such as structs, arrays, and etc. This is a LOT easier
than using the model and more intuitive from an end-users point-of-view.
Well, when creating an array of structures, the add-on that is part of
the language auto-generates the correct elements for a structure once
you initialize the appropriate reference elements.

Well, the GUI allows you to edit the complex type, which includes the
arrays by adding/removing/moving elements, without have to go back and
forth to the model (a very convenient feature). In the case of adding an
new element to an array and the element is a complex type as well, the
only way the add-on is able to generated the correct elements for that
new complex type in the model, which are needed by the GUI to function
correctly, is for the developer to *close* the GUI, which causes a
commit. They then must re-open the GUI and continue editing. This
becomes a hassle when dealing with large models.

Likewise, they may make some updates, but then decide to *cancel* their
changes. Well, there is now way to *rollback* all those changes without
forcing the modeler to remember what happened since the general
transaction has been committed. It seems this problem would be solved
with nested transaction support.

This is some functionality that our sponsors would like to have to make
the DSML we created more user-friendly. It is unknown how to make it
happen without support for nested transactions, or trying to emulate
them ourselves.

Or, any suggestions are welcome.

Thanks,

James

>
> --
> peter
>
>
>
> On Thu, Aug 5, 2010 at 7:52 AM, James H. Hill<hillj at cs.iupui.edu>  wrote:
>> Hi Peter,
>>
>> Ah, I see. Thanks for the quick reply.
>>
>> Are there any plans to make sure a feature available in interpreters? I can
>> see a case were you may have an interpreter that:
>>
>> . starts a root transactions
>> . makes incremental updates to the model in nested transactions
>> . commits its current modifications to force the *add-on* to execute
>> . commits root transactions once everything is complete
>>
>> I would think that nested transactions would make this use cause much 
>> easier
>> to implement without *duplicating* a LOT of code. Or, do you know a
>> workaround for *emulating* nested transactions in interpreters to prevent
>> duplicating a LOT of code or causing tight coupling of code?!
>>
>> Thanks,
>>
>> James
>>
>> On 8/5/10 8:42 AM, Peter Volgyesi wrote:
>>>
>>> Nested transactions are used only inside MGA (to implement add-on
>>> notifications in which add-on can further modify the models).
>>> --
>>> peter
>>>
>>>
>>>
>>> On Wed, Aug 4, 2010 at 5:23 PM, James H. Hill<hillj at cs.iupui.edu> 
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Does anyone know if GME supports nested transactions in it's
>>>> interpreters, and how to do so?!
>>>>
>>>> I see that there is an enumeration value TRANSACTION_NON_NESTED, but
>>>> there is no TRANSACTION_NESTED value. I only see TRANSACTION_GENERAL,
>>>> which seems to not support nested transactions.
>>>>
>>>> Any help would be greatly appreciated.
>>>>
>>>> Thanks,
>>>>
>>>> James
>>>> _______________________________________________
>>>> gme-users mailing list
>>>> gme-users at list.isis.vanderbilt.edu
>>>> http://list.isis.vanderbilt.edu/mailman/listinfo/gme-users
>>>>
>>
> _______________________________________________
> gme-users mailing list
> gme-users at list.isis.vanderbilt.edu
> http://list.isis.vanderbilt.edu/mailman/listinfo/gme-users
_______________________________________________
gme-users mailing list
gme-users at list.isis.vanderbilt.edu
http://list.isis.vanderbilt.edu/mailman/listinfo/gme-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5113 bytes
Desc: not available
Url : http://list.isis.vanderbilt.edu/pipermail/gme-users/attachments/20100806/a580edff/attachment.bin