Filters for the AI field + user editable text

[dev-rd]

@olgatrykush Are filters for the AI field in the pipeline?
Same question for user editable text in the AI field.

I thought I’ve seen this feature suggested somewhere but a quick forum search does not yield results.

Currently the workaround for filters would be to use formulas, but again with many AI fields one ends up with way too many columns. I’d be most interested at the very least in the “contains” and “does not contain” type of filters for the AI field.

For the editable text -the workaround would be to copy-paste to a TXT field - but for larger datasets this is cumbersome or requires automation overhead thus limits the non-technical users significantly.

[olgatrykush]

Hi @dev-rd, I haven’t seen these features mentioned before, so I’ll check with the team about our plans to add them. I’ll keep you updated.

[olgatrykush]

Hey @dev-rd, both requests have been accepted. We’ll make it possible to edit the AI fields and enable all compatible filtering for the AI field.

[olgatrykush]

To edit an AI field, use this workaround: create a formula field that references the AI field, then convert it to a text field:

[dev-rd]

Thanks - is there any difference for the table (performance, data integrity, etc?) if I duplicate the AI field/column and change the duplicate to text? Is the “formula” method better in any way?

That is a bit related to my other question here:

Baserow - column and cell limits

Are you using our SaaS platform (Baserow.io) or self-hosting Baserow? Self-hosted If you are self-hosting, what version of Baserow are you running? 1.31.1 + env variables (to edit more than 200 rows) If you are self-hosting, which installation method do you use to run Baserow? single image docker container What are the exact steps to reproduce this issue? It’s a more general question about the expected limits of Baserow (1.31 and later). I need a table for a project, which may require more t…

[olgatrykush]

Hey @dev-rd, the formula option is faster since you don’t need to copy texts manually—you just create two new fields. However, neither option is perfect. When the text is copied and you regenerate the prompt, you’ll need to manually update the outputs in the copied fields, which affects data integrity.

We aim to add the ability to edit AI field outputs as soon as possible. I’ll let you know as soon as the issue is created and scored.

[dev-rd]

Actually I was wondering about the difference between:

A) duplicate AI field → change field type to text (long text+ rich formatting)
vs
B) use Formula → change field type to text

OR
C) stay with the formula for filtering for as long as possible (but that I assume may slow large tables down if there are many such columns).

however - the underlying questions for both A and C is:

1. Do frequent changes of field types degrade database/table performance over time.
   (frequent = I would need to change at least 40 - 50 columns a few times a month each)

2. Can the above eventually break tables (as in corrupt to a point where adding new columns is problematic and adding new data via import does not work properly)?

[olgatrykush]

Hi @dev-rd, I’ll check with the team and get back to you.

[dev-rd]

thanks - I partly got the info I needed regarding the “underlying” question from the other thread, but if you have any more insight about the issue this will certainly be very useful.

[olgatrykush]

Hi @dev-rd, I checked with the team, and here are the answers:

@dev-rd

Do frequent changes of field types degrade database/table performance over time.
(frequent = I would need to change at least 40 - 50 columns a few times a month each)

No, this won’t impact performance.

@dev-rd

Can the above eventually break tables (as in corrupt to a point where adding new columns is problematic and adding new data via import does not work properly)?

No, it also should not break any tables.