in procedure TEchoRouter.RouteToNodes(ALog: TEchoLog; ABatches: TArray<TEchoBatch>); there
are created TEchoLogBatches if routing conditions are ok.
However, if a lot of records are filtered then function TEchoRepository.GetFailedIncomingBatches needs to handle a lot of unnecessary (slow) batches in client pull because there are batches without ECHO_LOG_BATCH-relations.
I'll added there now skipped status and use in RouteToNodes if not DoRoute
Batch.Status:=TBatchOutgoingStatus.Skipped;
Could there be something like this in official version also?
Please correct me if I understood it wrong. But from what you say, it looks like your are mixing the batch with the batch items (logs). The RouteToNode "event" is an opportunity for you to filter what BatchLogs will be routed to the node. In a single Batch, you might have logs that are routed, and some that are not. It doesn't make sense to flag a whole batch "skipped" or not, because it depends on each log item?
yes, I understand this and I am filtering logs using RouteToNode-events. In my case maybe only 5-10% of logged changes are finally routed. In current approach there will be batches even if there are no logs in that. This will lead to heavy load queries in mobile node which in the worst case will be ended by timeout. GetFailedIncomingBatches can try to retrieve tens thousands of rows for client node pull even if there are no echo_logs.
Now as workaround I have sql server jos as:
UPDATE A
SET A.STATUS=3 --skipped
FROM ECHO_BATCH A
LEFT JOIN ECHO_NODE B ON (B.ID = A.TARGET_NODE_ID)
LEFT JOIN ECHO_LOG_BATCH C ON (C.BATCH_ID = A.ID)
WHERE
A.STATUS = 1 -- 1=Pending batches
AND C.LOG_ID IS NULL --Filtered, no log association
I think I understand now. In this case I believe instead of flagging a batch Skipped, it would be better to just not create the batch at all, if there are no logs? If that's correct, please contact us through e-mail so I can send you a patch for that.