In order to migrate data storage from a previous solution into baserow, I need to keep a unique ID updated across multiple table. Let’s call it cmdbId.
Automatically incrementing that number isn’t a problem, I’ve created a separate table that can hold different values, and that ID is one.
When a new row is created in one of the tables in question, I call a webhook of n8n which first reads the old value, increments it and writes it back (making that atomar is another issue, but due to low turnover, not a priority). Once that is done, I update the table that caused the webhook to be called. I have the table_id and the row id of the new entry. Anyway, when I try to update that row dynamically, it doesn’t work. When I have the table and field more or less static, it works fine, but once I use the changing input from multiple tables, it doesn’t work; the update function complains that the table name, table ID, field name (to update) are invalid.
While I only have to tables at the moment, duplicating the webhook function for different tables would be doable, but undesirable, because for every additional table, I’d have to duplicate and adapt the workflow again.
In the last baserow component (updateTargetTable), I’ve tried using either the table name or table ID as dynamic input, the field name I’ve tried both fixed as well as dynamic input … seems to me like the call only work when the data present during test was valid and somehow stored, and the field ID matched with the latest call …
Please share the workflow
Information on your n8n setup
n8n version:0.203.1
Database you’re using (default: SQLite): Baserow
Running n8n with the execution process [own(default), main]:own
Running n8n via [Docker, npm, n8n.cloud, desktop app]:Docker
Hi @Garry, when using the Baserow node you’d need to make sure your expression resolve into valid IDs. n8n might not be able to verify their validity, but as long as Baserow understands them you should be good and can ignore the warning you are getting from n8n:
The Database is a constant, so that ID isn’t a problem …
I believe the problem is somewhere in the resolving part … could it be that resolving happens at the point of creating the node, but not runtime?
I will try to come up with some code fragment that will test for the theory …
Oh, I might have misunderstood you then. Expressions are resolved at runtime though, so if you use an expression such as {{ $now }} this would return the time of execution, not the time it has been added to the workflow.
Of course THAT works … but it seems as if the Baserow evaluation doesn’t work like that … I just can’t seem to dynamically select a TABLE NAME or FIELD NAME, while using a TABLE ID as variable does work … so, while the GUI states I can use either a table name or table ID while editing a node, the name always seems to be converted to an ID.
Check out this example:
In Baserow, I created a database, added a table “Table1” with just the default schema and content. In my example, the table’s ID was 538.
In the top workflow, I have a variable that contains the table ID, which is then successfully executed by the Baserow node.
The lower part of the workflow references the table by name, which fails. So, in essence, it seems that the Baserow node just doesn’t evaluate names on execution, it will only allow IDs to be dynamically fed into it.
Oh, I see what you mean now. Yes, this is unfortunately very confusing and I don’t know the UI is like that. You would indeed need to specify an ID when using expressions here.
If you don’t have the IDs available, you could consider using the HTTP Request node to manually list the existing tables via the Baserow API to find the correct table ID for a given name.
