@olgatrykush I have checked @AnnaRiis’s thread, however, it’s been 3 months without any ETA on a core database field functionality.
I am sure there are a lot of issues and other tickets, so let me give you an example about why this should be prioritized from user perspective and its in the company’s best interest to do so.
Basically, when you make two indepent formula calculations across any 2 tables in Baserow, you can’t recombine them. Formula + Formula = {rollup breaks}
That leads to numerous issues when dealing with anything more complex than simple formulas, because you have to convert the formula result into a value.
Now, in Anna’s case that might be a simpler rollup, but when you use Baserow as part of a software, if you have a database table with say 10,000 rows, instead of using the database rollup field, you have to bypass that limitation programatically. That leads to numerous API requests and slows down the entire software application, no matter how well optimized it is, even if it’s just for a few requests.
Meanwhile, if the rollup field works, all the calculations happen on a database level and the output value is in the database, there is no need to recalculate it programatically.
This is not about Kuma AI, or some workarounds. This is a core functionality that defines IF Baserow will be used into more complex software applications, or if it will remain a database that’s preferred only for basic smaller apps.
What needs to happen is that the engineers figure out a way to convert the formula values into readable format, so that the rollup field recognizes them and is able to perform the rollup when the source is a *formula field (*prioritizing numeric values).
Again, Kuma AI is a helper, and the new automation builder is great, but you can’t solve everything with a workaround.