Using Xano Pattern filter (Regex) doesn't give expected results

Ambroise

I've added a column with a Pattern filter, as such:

The pattern is: `/\b(1[0-2]|0?[1-9]):[0-5][0-9] [AP][M]\b`

Il also tried `\b(1[0-2]|0?[1-9]):[0-5][0-9] [AP][M]\b`

But it doesn't work, I can write any kind of text in the column, it doesn't get rejected.

Although, I've tested that regex at https://regexr.com/7i09e and it provides expected results.

Does Xano expect a different format?

Ambroise

Similar issue with another Pattern:

^(?:1?\d|2[0-3])h(?:[0-5]?\d)?$

But Xano allows things that shouldn't be allowed:

Ambroise

Well, my filters for Integer are being ignored as well, I guess all Filters are broken at the moment.
https://watch.screencastify.com/v/tT32QLC9K8XuDMeTuh4y

That's really unexpected and quite disappointing.

Ambroise

Or, filters are only being applied when data is manipulated from the API endpoints.

But, if that's the case, that's even more terribly disappointing, and quite unexpected.

Ambroise

Enforcement will be on the business logic aka your API. So when data is getting added through your API from your front-end, these rules will be enforced. - Xano support

Unfortunately, the database itself doesn't ensure any data rules (filters/patterns), meaning any developer can write about anything directly from the Xano UI. Only data sent through API endpoints will have filters applied on them.

This doesn't help testing filters, is not made obvious from the Xano UI (not stated anywhere), and doesn't follow database best-practices. I'm not sure if it is planned to change that behavior at some point, but I would guess it's not.

Supabase handles that gracefully, and nobody can write data that don't match the column rules, not even developers, and that's how things should be.

Sean Montgomery

@Ambroise sorry the database view isn't living up to your expectations. The database view is designed as a way to work with your data without limitations. Sometimes you need to work with your data in multiple steps and you can only do that when the filters aren't being enforced.

Our RBAC addon lets you control who has access to the database. You could disable access to your developers or perhaps give them read only access. That way they would only be able to modify data through the APIs and Functions.

I do see your point though. Clearly you want it to work differently than we want it to. Perhaps we can look into a strict mode to enforce the filters in the database view.

The community is great for stuff like this. Please continue to provide feedback as it helps us improve the product.

Ambroise

Well, my point is that I want my data to be 100% safe.

With this design, there is no safeguards for data written outside of the API endpoints scope. Developers manually updating data through the UI isn't necessarily the most common issue, but with additional features like SQL queries added recently (inserts, updates), it becomes possible to "mess things up", while my goal/hopes were for the database to refuse writing any kind of data that doesn't pass the filters.

Nothing stops me from writing a bad script that will store wrongly formatted data into my DB using a cron, for instance. And that's one of the pitfalls I had hoped to avoid.

Ambroise

In today's newsletter, I find this wording untrue/misleading, as it makes believe the schema is applied at the DB-level, while it is really only applied at the API-level.