On 10-11-26 04:20 PM, Christopher Browne wrote:
> Jan Wieck<JanWieck at Yahoo.com>  writes:

>
> 1.  Drop TRY, so people don't make the mistake of imagining
> transactional safety that's not there.  If we add "automatic waits,"
> we're likely giving up on the capability of TRY.
>
> 2.  Define clearly what things are allowed in a TRY block and what
> things are not, so that the slonik parser forbids invalid actions.
>
> I'm not sure if that's plausible.

Well what can't be in a TRY?
Anything that you need to wait for to propogate to another node.

When do you need to wait for something to propagate to another node?

Any time the event node of a subsequent command is different than the 
event node of the current command.  The subsequent command might change 
the other node before (or after) the first command is replicated. 
Depending on the nature of the commands this might or might not be an issue.

I also want to point out that some commands have an implicit event node. 
  ie store path.

Slonik knows the event node of each command before it starts executing 
anything(1). (either the event node is specified or slonik infers it 
from another parameter).

I think we want to write some code in slonik that walks the parse tree 
and looks for any time the event node will change.  If so we would then
a) Make sure that this isn't happening in a TRY block. If so error out 
(at parse time).

b) Add an automatic wait to make sure that the previous event on the 
current event node has been confirmed by the next event node (or does it 
have to be confirmed everywhere?)


Footnotes:

1) This isn't actually true.  In 2.0.5 for subscribe set, slonik 
interogates the cluster to find the current origin of the set.  It picks 
this as the event node.  Jan has said that the original idea for 
subscribe set was that the receiver would be the event node.  That would 
solve this.  The other case is FAILOVER that gets the most-ahead node at 
the time it runs.   This is kind of special anyway because if your using 
FAILOVER chances are some node isn't confirming events anyway.



>
> These items are evolutionary changes, not revolutionary.
>
> If we're to have something altogether replacing Slonik, I'd think:
>
> 3.  It needs to have a new name, so people don't confuse "old Slonik"
> with "new Slonik."
>
> I have worked on projects where they tried desperately to retain the
> same name for fundamentally different designs, and this causes no end of
> confusion.
>
> 4.  We need an overview of what the new tool is, and the qualities that
> define it.  It should be possible to have a fair bit of detail of things
> the slonik replacement does and doesn't have.