[solved] Delete Rule Keeps Retriggering

Squiffy

I have two processes.
Both processes work perfectly if run from the menu in testing mode.

If they are triggered by a rule in the "Rules (when object is deleted)" section of a BO, the whole rule keeps getting re-evaluated as true until I restart everything.

I'm sure the second process is the culprit - if I remove it or change it the retriggering doesn't happen.
It does this :

CREATE TempVars WITH TempVars.TempNumber=1  // A non-persistent BO
FIND ALL CallerNumber IN BATCHES OF 1
CallerNumber.Sequence=TempVars.TempNumber
INCREASE TempVars.TempNumber BY 1

It is resetting a sequence variable to be contiguous after a deletion (so I can randomly select from it elsewhere).

My delete rule currently just calls the processes in order with no IF clauses, as I thought it might only trigger the once.

Do I need an IF clause? If so, what? Nothing strikes me as obvious, and I can find nothing obvious in the manuals about what to look out for when creating delete rules to stop retriggering. Or am I barking completely up the wrong tree?

Been at this all day - any help gratefully received.

Squiffy

I've attached a test project with an example if anyone fancies having a look. I'd be very grateful.

Steps to reproduce :
Load up a few numbers into the MyNumbers BO (eg, 101,102,103,104, etc)
List them, edit one of them and click the delete button.
Goes into a tail spin.

If you keep refreshing (or watching the log file) you can see it's doing what I expect in terms of resequencing, but it just keeps repeating until you stop the application.

EDIT -
it's to do with the IN BATCHES OF, I think.
If I remove that bit then it doesn't lock up (it just merely doesn't work as it changes all of the results in context to 1, as I would expect it to hence the batches).

DeleteTest.zip

34.91kB

DeleteTest.zip

34.91kB

Squiffy

Sorry to bump this thread, but I'm so sure I'm missing something simple that it's frustrating me.

The process ProcSequenceReorder is in batches of 1 so it gets paused and restarted as many times as there are instances of the BO but I just don't see how to stop the Rule attached to the delete event of the BO (which calls this process) from re-firing once the Process has completed it work on all remaining BO instances. Once that happens the process repeats endlessly.

I'm probably trying to shoehorn existing methodologies into the AIM system, but I would really appreciate someone's input on this. I really cannot see the wood from the trees now.

pureist

I think your approach is wrong, and some other general things:

General: Instances are always singular, thus Object names should never have 's' at the end.
...eg. an order lines object should be named OrderLine, not OrderLines
...you are never creating multiple order lines at once with CREATE. you are creating one instance at a time
---so CREATE OrderLine is the way it should read when you create a order line, not CREATE OrderLines
....proper naming, when replicated throughout an entire application, makes for a much more readable and followable application
....plural naming should only be used when naming reference attributes. eg. the OrderHeader Object would have a RA named OrderLines, which reflects the underlying 1:many relationship
....I don't know if your sample bsv is indicative of your applications in terms of naming, but it seems logical to be consistent in terms of 'standards' even in sample bsv's which you are asking others to review/follow
Approach: Never use IN BATCHES OF 1. IN BATCHES OF should not be used for processing individual records. It is server intensive and thus, slow.
Only use IN BATCHES OF if the ResultSet is going to be so large that it might tie up the server and delay other users access. IN BATCHES OF 500 or 1000 is probably the first tier at which you should consider using it.

2b. to process records of a ResultSet individually, instead call a subprocess at the Action immediately after the FIND. Each record found will be processed individually by the subprocess. Thus the subprocess will contain the actions which process each record. Once every record of a ResultSet has been processed, any actions after the Action which called the subprocess will be carried out.

Approach: If you are deleting 1 record, why do you want to waste time and resources renumbering all records?
Surely you just want to 'compact' them, by only renumbering the records which have a higher sequence number than that of the record which was deleted?

Will post a bsv later.

Squiffy

I think your approach is wrong,

Almost certainly.

General ...

I recognise I make those mistakes still - though less so as time goes on - but in my (slight) defence the BSV you see before you was named without much care for a quick example to reproduce my issue. Points all noted though.

I agree with your general point about compaction from the point of deletion, and I'm considering doing that, but I believed the same issue would result (the only difference would be a filtered result set from the WHERE clause). There is also something to be said for assuming nothing about the existing ordering when performing this task, just in case, though the point is noted on performance. I can weigh those points up once I can get it working at all.

2b. to process records of a ResultSet individually, instead call a subprocess immediately after the FIND. Each record found will be processed individually by the subprocess.

I will test that now. I didn't realise that.

In answering this post I've come to think the real point of this is to understand why the retriggering takes place at all.

Thanks for your help.

pureist

"2b. to process records of a ResultSet individually, instead call a subprocess at the Action immediately after the FIND. Each record found will be processed individually by the subprocess. Thus the subprocess will contain the actions which process each record. Once every record of a ResultSet has been processed, any actions after the Action which called the subprocess will be carried out."

Note, "..instead call a subprocess at the Action immediately after the FIND. Each record found will be processed individually by the subprocess.", from the above paragraph, ALSO includes where the Action next after the the FIND is in the next Rule to the one containing the FIND (ie. the FIND is the last Action of the Rule).

Attached is a bsv which, if you invest some attention to detail in following through the 'flow' (in the bsv) of what happens as a result of each user interaction, illustrates some useful concepts.

One of which is individual record processing with 'compaction' and 'expansion' of sort sequence when a record is deleted or inserted, using subprocesses and object prefixes. To make it clear to follow, records don't get deleted, but instead flagged as deleted via a Status attribute, though obviously they could instead just be deleted.

sequencing.zip

36.35kB

Squiffy

Ok, this seems to work.

Under "Rules (when object is deleted)" I'm setting Sequence to -1 to tag the instance being deleted. Is there a more AIM-way to exclude this (I suppose "current") instance from future processing?

I then call my processes, adjusting the FIND ALLs to FIND ... WHERE Sequence <> -1

That tip on sub processes only processing one instance at a time was the key for me, thank you a thousand times for that. So I can embark on a ritual of self flagellation for not finding out myself - is that action described in the manual somewhere?

Cheers.

Squiffy

Pureist :

our posts crossed!

Thank you for your time, I will study what you have done for me.

Many thanks again for your help.

pureist

Forget about messing around with -1 and all that stuff. It's all superfluous and unelegant.
Get into the guts of the bsv and take note, following FIND's, of the use of the 'This' and 'Other' prefixes used with Object names, and how the relevant instances in context following a FIND are passed to the subprocesses via '..USING Other..'. .
AND, memorize the prefixes:

'This' refers to the first Instance in context.
'That' refers to the second Instance in context.
'Other' refers to all Instances in context except the first.

Squiffy wrote
Ok, this seems to work.
Under "Rules (when object is deleted)" I'm setting Sequence to -1 to tag the instance being deleted. Is there a more AIM-way to exclude this (I suppose "current") instance from future processing?
I then call my processes, adjusting the FIND ALLs to FIND ... WHERE Sequence <> -1
Cheers.

IF you wanted to persist in doing it this above way, you wouldn't use -1. You would instead make the FIND:
FIND object_name WHERE object_name.ID <> Thisobject_name.ID

Squiffy

IF you wanted to persist in doing it this above way...

Nope, I much prefer your way using those modifiers (that was the more AIM way I was looking for). The -1 was only to exclude it from the reordering before ultimately being deleted.

Helps tremendously to see it in use. Thank you so much for taking the time.

customaware

Dave,

Here is some stuff on how to use 'Other'

HOWTO Other.zip

68.06kB

Squiffy

Thanks, Mark.

Jaymer

pureist wrote
Approach: Never use IN BATCHES OF 1. IN BATCHES OF should not be used for processing individual records. It is server intensive and thus, slow.
Only use IN BATCHES OF if the ResultSet is going to be so large that...<snip>.

Nice tips in this thread. I appreciate it.

But I'm confused about something here... I experienced something, and even saw another newbie seeing the same results and my suggestion to him was to add "Batches of 1" and it solved his problem.

From what I can recall, I just wanted to do a vertical update on a field... probably I made a new field and wanted to set its value to some formula to load the column - just like I'd do in native SQL.
The problem was that the result string calc'd fine for the 1st record, and then populated that on ALL the other rows in the table.
It didn't seem to calc correctly without "batches of 1"

Can you help me understand why we saw that behavior?

pureist

"The problem was that the result string calc'd fine for the 1st record, and then populated that on ALL the other rows in the table."
Those other instances must have been in the context at the time the Action with the 'result string' was executed.
Maybe just using the 'This' prefix would have resulted in the desired outcome? Depends on what exactly you were doing.
Per previous post:
"2b. to process records of a ResultSet individually, instead call a subprocess at the Action immediately after the FIND. Each record found will be processed individually by the subprocess. Thus the subprocess will contain the actions which process each record. Once every record of a ResultSet has been processed, any actions after the Action which called the subprocess will be carried out."

Note, "..instead call a subprocess at the Action immediately after the FIND. Each record found will be processed individually by the subprocess.", from the above paragraph, also includes where the Action next after the the FIND is in the next Rule to the one containing the FIND (ie. the FIND is the last Action of the Rule).

I suggest exploring the guts of bsv I posted earlier this thread for Sq. It illustrates core fundamentals re. context and object prefixes, via a mini application which moves instances out of and inserts them back in to a sequence, reordering the sequence numbering accordingly.
I found it to be a really worthwhile time investment to get a good handle on Context and object Prefixes.
Once you're on top of context and object prefixes, you can do beautiful things.

Squiffy

The instinct for me was to try and loop through the result set, using BATCHES OF 1 because I'ma traditional programmer.

Getting my head around how to manipulate the context is challenging when I'm very ingrained in a different way of thinking.

But I get it, I just don't think like it yet without concentrating. The two examples in this thread were helpful.