I would like to know if there is some way to trigger the data-update for APPS that is usually triggered by “Datatable Save” or “Advanced Input Table-API” for a “database-view data table” (perhaps using some API-call?)
Scenario:
External postgresql database (DB) with “Table_a”
OD data table “DB__table_a” created from a “Connection” to the DB for the “Table_a”
APP which displays DB__table_a and uses “saveToMicroservice” to trigger a workflow which will then modify “Table_a” in the DB directly.
Ideal solution:
SaveToMicroservice-workflow will call some API / do some trick to trigger the data update in APPS for the view-datatable (instead of saving a copy as “real” datatable, see below)
Current solution:
Currently, we do not use a data-table view but save the changed table in the workflow again as “real” data-table to get the “pushed” update in APPS. But this approach has multiple problems (ineffective, type-casting-hell, python-processor-has-only-single-output-issue) and it would help us a lot if we could cut out this duplication of resources.
Maybe I’m not getting the problem correctly so two questions on that:
Is Table_a a view?
If yes: Does the WF that gets triggered therefore write to an underlying table(s) for the view?
Technically, I can’t imagine limitations (if we’re dealing with a table, not a view here) when it comes to writing to external DBs. It might be limited due to safety reasons. Is a direct interactions with the data table in OD possible (“edit button” in Data Detail page)?
Table_a can be a view in the db or not, that should not matter - let me phrase the problem in a different way (my problem is not “writing” to the database but “reading” from it for Apps):
Currently, when a data-table is a “view” on a table via a connection, any change to the external database will not trigger any data-update in an App that uses this “view” as dataSource.
What I would need is some kind of manual “trigger” that tells the OD-backend (or Apps?) that the data in the database changed and now please do your magic and push that to Apps as it is done for any “real” change via “datatable save” or using the “/data/content”-endpoint to change the datatable
Ah I see. So external applications (not Apps, not OD) change the content in the table, correct?
If that’s the case, imho, the changing system or DB system itself needs to “take the lead here” and notify either OD or Apps.
Your scenario is more in an event-driven context. Usually DBs are rather passive so I’m not sure if there is any such functionality out in the world offered for your target DB. Maybe you should rather have a look at the external origin of the changes… maybe you can trigger an event in OD from there, after a successful change to the table was done by the external application.
If you really really need this to be done by ONE DATA, surveillance is the only solution I can currently think of. In order to actively recognize changes to the tables inside the DB, ONE DATA could poll data (or metadata - which would be the better solution but may or may not be feasible in your target DB) on a scheduled basis.
I’d really recommend taking a step back and look at the origin of the changes. Usually it’s the best place to trigger updates in dependent resources (be it directly or via an event bus otl).
Sorry, as I wrote, the topic is not easy to grasp, but I think you get it wrong: I have full control over the change to the external database and know when something happened, the only part missing is that I can’t notify ONE DATA or Apps about this change.
Basically:
User A changes Table_A in Apps
Apps calls workflow in OD via “saveToMicroservice”
Workflow makes changes to external DB via Python processor
MISSING: Workflow should notify OD/Apps that Table_A changed
Small summary for future readers after discussions: It is not possible using any official feature / API endpoint, possible workarounds are available but not ideal.
Therefore a feature request will be created to discuss the possible advantages / disadvantages of allowing “external” tools to notify ONE DATA about changes in external databases.