Transaction editor

[danionita]

When two or more transfers depart from the same port, it implies an OR (either transfer 1 or transfer 2). This creates two ambiguities:

• What are the proportions with which each transfer takes place?
• Is several ports of the same interface have multiple outgoing transfers, then which transfers should be grouped as transactions?

To solve this, we need a manual transaction editor, just like in the old tool. This editor should allow the user to manually group transfers into transactions, and then assign FRACTION attributes to each defined transaction.

[bobismijnnaam]

Is the only extra thing needed the fraction attribute or should the user be able to set arbitrary formulas on a value transactoin? If so, I'd like to integrate the "fraction setting" part into the value transaction collection editor, instead of using the e3properties window.

[bobismijnnaam]

And is fraction a decimal or integer?

[bobismijnnaam]

Something like this

[bobismijnnaam]

Gave it some thought, and it's probably better if we just reuse the properties window.

[bobismijnnaam]

As of 96d73e9b18ad215fc02a914f9a7e6bcd84dc8f3f value transactions should work, without do/undo support.

Some points:

• Right now value transactions can both be derived & specified by the user. I.e., if the user specifies no value transactions, the RDFExport class will group all exchanges by value interfaces and assign value transactions that way. However, if the user only specifies value transactions for half of the value exchanges, the situation becomes ambiguous. Four choices can be made:
  • Also "naively derive" value transactions for the exchanges that are specified by a value transaction, effectively discarding the user's specified value transactions
  • Only "naively derive" value transactions for exchanges which are not assigned to a value transaction
  • Only keep the value transactions specified by the user, and leaving the value exchanges "orphaned" (i.e. don't "naively derive" value transactions for these exchanges)
  • Ignore all, i.e. disregad any value transactions specified by the user and don't "naively derive" any value transactions. This effectively breaks the NCF module.
• Right now the second option is used everywhere (i.e. keep the user specified vt's, and generate vt's for orphaned ve's), but it's trivial to switch (I've implemented them all and the mode can be specified with an enum.)

So, two questions:

• Do we want proper do/undo behavior? I suspect this is hard but doable, but if I would implement this I'm not sure if there would be enough time to implement find as well.
• Is the default value transaction derivation mechanism the right one? It's trivial to change but I want to hear your thoughts as well @danionita

[danionita]

Right now the second option is used everywhere (i.e. keep the user specified vt's, and generate vt's for orphaned ve's), but it's trivial to switch (I've implemented them all and the mode can be specified with an enum.)

Great.

Do we want proper do/undo behavior? I suspect this is hard but doable, but if I would implement this I'm not sure if there would be enough time to implement find as well.

Not necessary.

Is the default value transaction derivation mechanism the right one? It's trivial to change but I want to hear your thoughts as well @danionita

Out of the four options, it sounds to me like the one right one. However, I am curious how you currenlt handle the situation when, for instance, only some of the VTs which are part of a VI are grouped together and the others not? Do you add the missing ones to the group, or create a new group?

[bobismijnnaam]

The intended effect that works right now is that every ValueExchange that is assigned to a VT is ignored (since it is alreayd part of a VT). For all the VE's that are left, they are grouped by pairs of value interface, and these all become separate VT's. So if there's a pair of value interfaces with both having 3 value ports, and only two of the three value exchanges are assigned to a value transaction, another (new, separate) value transaction will be created for the third (orphaned) value exchange.

On 6 February 2017 at 15:16, danionita notifications@github.com wrote:

Right now the second option is used everywhere (i.e. keep the user specified vt's, and generate vt's for orphaned ve's), but it's trivial to switch (I've implemented them all and the mode can be specified with an enum.) Great.

Do we want proper do/undo behavior? I suspect this is hard but doable, but if I would implement this I'm not sure if there would be enough time to implement find as well. Not necessary.

Is the default value transaction derivation mechanism the right one? It's trivial to change but I want to hear your thoughts as well @danionita https://github.com/danionita Out of the four options, it sounds to me like the one right one. However, I am curious how you currenlt handle the situation when, for instance, only some of the VTs which are part of a VI are grouped together and the others not? Do you add the missing ones to the group, or create a new group?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/danionita/e3tools/issues/90#issuecomment-277693834, or mute the thread https://github.com/notifications/unsubscribe-auth/AC8IaNLOPHyy_LZgx2xodbMIhA06cIyPks5rZytbgaJpZM4LeRpC .