Persistent Feeder query
Posted: Mon Apr 26, 2021 12:03 pm
I had an interesting experience "at" a client site on Friday, running PAL 2.0.92.19., the initial build of the application having been done by a third party. (apologies for the long post, btw)
We were getting some mysterious behaviour on the feeder side of the model and had established that a feeder for a particular rule was missing but the rule was partially working because of flags in a persistent feeder file.
Sequence of events as follows with Persistent Feeders on.
1. Feeder written and saved, the right hand side of the feeder contains a lookup to redirect depending on the left hand side. The lookup cube was incorrectly populated in some cases. For those cells where the lookup cube was correctly populated the feeder worked and for those that weren't the feeder didn't. As expected.
2. Lookups corrected and feeders recompiled via, resaving (rules invalidated to trigger feeder compile), via TI command and by unloading and reloading cube. None of these steps corrected the feeder, only the cells correctly fed in step 1 worked.
3. Using Trace feeders indicated that the destination cells were fed in all cases. (though this only displays what should be happening, not what actually did happen at compile time.)
4. We deleted the .feeder file on disc (without restarting) and recompiled the rules. .feeder file rebuilt but the newly introduced feeder statement was not working at all, i.e. both the working and not-working from step 1 were failing.
5. We tried various forms of the feeder including a single explicit fully qualified cell on the left to the destination, none of these worked although they all showed up in the trace feeders with multiple traces showing up for each of the various ways we wrote the feeder.
6. We entered a new value in the feeder source, changing a null (0 in the cube viewer) to a value. The feeder correctly triggered for that cell.
7. A stop of the DB, deletion of the .feeder file adnd then DB start corrected the issue.
8. We've not had chance to test the behaviour with persistent feeders off.
9. We also checked the rule .blb for any differences, there weren't any.
Conclusion.
A. The feeder was written correctly or 6 would not have happened.
B. Feeders were firing for new data points
C. The recompile of feeders for existing data was failing but apparently only for the new feeders (or the .feeder file wouldn't get being rebuilt).
Query.
My view is that we've hit a defect but I just want to sense check if the above could be considered expected behaviour of persistent feeders.
We were getting some mysterious behaviour on the feeder side of the model and had established that a feeder for a particular rule was missing but the rule was partially working because of flags in a persistent feeder file.
Sequence of events as follows with Persistent Feeders on.
1. Feeder written and saved, the right hand side of the feeder contains a lookup to redirect depending on the left hand side. The lookup cube was incorrectly populated in some cases. For those cells where the lookup cube was correctly populated the feeder worked and for those that weren't the feeder didn't. As expected.
2. Lookups corrected and feeders recompiled via, resaving (rules invalidated to trigger feeder compile), via TI command and by unloading and reloading cube. None of these steps corrected the feeder, only the cells correctly fed in step 1 worked.
3. Using Trace feeders indicated that the destination cells were fed in all cases. (though this only displays what should be happening, not what actually did happen at compile time.)
4. We deleted the .feeder file on disc (without restarting) and recompiled the rules. .feeder file rebuilt but the newly introduced feeder statement was not working at all, i.e. both the working and not-working from step 1 were failing.
5. We tried various forms of the feeder including a single explicit fully qualified cell on the left to the destination, none of these worked although they all showed up in the trace feeders with multiple traces showing up for each of the various ways we wrote the feeder.
6. We entered a new value in the feeder source, changing a null (0 in the cube viewer) to a value. The feeder correctly triggered for that cell.
7. A stop of the DB, deletion of the .feeder file adnd then DB start corrected the issue.
8. We've not had chance to test the behaviour with persistent feeders off.
9. We also checked the rule .blb for any differences, there weren't any.
Conclusion.
A. The feeder was written correctly or 6 would not have happened.
B. Feeders were firing for new data points
C. The recompile of feeders for existing data was failing but apparently only for the new feeders (or the .feeder file wouldn't get being rebuilt).
Query.
My view is that we've hit a defect but I just want to sense check if the above could be considered expected behaviour of persistent feeders.