Why can't I sometimes enforce an id type input parameter to be minimum 1?

arturosanz

This doesn't happen always, but I couldn't figure out when or why it happens or not.

Let's say I need to add a record and one field is a reference to a record in another table. In the example below I want to add a new car record that has a relationship with a driver, so there is a "driver_id" field I need to fill in. Ok, so the endpoint has an input of type integer called "driver_id" which in my case is required and its value must be 1 or greater. I didn't set any default value.

For some reason I don't understand, I get this error "Param: driver _id - Invalid method for filter - min" when the "driver_id" input value is valid, for instance 2. See the screenshots below.

I have other similar endpoints with the same "min 1" filter applied to this kind of "id" input and they work perfectly fine. Some work well but some don't.

Anyone knows why?

Arturo

Liz Anaya

Hi @arturosanz!

Thank you for bringing this up. Our engineering team is looking into this, and we'll keep you posted. In the meantime, changing the input to an integer type instead of a table reference should fix this.

Let me know if this works on your end. 😊

Liz Anaya

@arturosanz I was able to replicate this on my end. I see that the first_notempty treats "0" as an empty string "". Thank you for bringing this up! We're looking into it.

Liz Anaya

Hey @arturosanz!

Tthe first_notempty filter considering the string "0" as an empty value (like "") is expected behavior. The filter first_notnullwould be the appropriate one to use if you are wanting to use 0.

Liz Anaya

Hey @arturosanz!

For the first item, where false == null returns trueby the == operator:

• Using == will test for the boolean value, causing the statement to return true
• Using === will test the type so false === null will return false

I was able to replicate the second item, and we are looking into it!

Thanks for bringing this up, Arturo!

arturosanz

Thanks Liz. The workaround works.

arturosanz

@Liz Anaya just to let you know that the first_notempty filter considers the string "0" as empty value (like "").

arturosanz

@Liz Anaya I have two other "strange" situations that I want to share with you.

1. Nullable boolean inputs

For some reason WHERE statements like boolean_input == null return true when boolean_input is null but also when boolean_input is false. So false is treated both, as false and as null by the == operator, which makes impossible to distinguish between sending the input value false, or not sending the input value at all. This is a problem when editing boolean fields from an API endpoint.

Thankfully, there is a simple workaround. If we apply the is_null filter to the boolean_input in a WHERE statement like this: boolean_input|is_null == true, then it works well and distinguish between null and false values perfectly. See the screenshots below.

2. Timestamps fields with value 0 shown as empty

Timestamps are nullable by default. However, if we erase a timestamp field directly on the table from the Xano interface using the delete key of the keyboard, for some reason Xano saves the value 0 instead of null but we see the field empty. This is a problem because 0 is a valid date (Thu Jan 01 1970 00:00:00 GMT+0000) but the record field looks empty in the table though it is not empty.

Thankfully this only affects to the Xano database interface which shows the cell empty in both cases, not only when the field value is null but also when the field value is 0 = Thu Jan 01 1970 00:00:00 GMT+0000.

If you try to input that date from the Xano date picker you will see the cell empty. It is the only valid time stamp that won't be rendered, but it should be because it's not empty. Basically, any timestamp field in which you save the value 0 = Thu Jan 01 1970 00:00:00 GMT+0000 will be shown empty in the Xano interface, which creates confusion. See the screenshots below.

null and 0 are both shown as empty cells.

arturosanz

@Liz Anaya the problem with the === operator is that it is selectable in if-then-else conditions but not in WHERE clauses (QueryAllRecords).

Liz Anaya

Hey @arturosanz!

I looked into this and was able to filter the results from a Query All Records function based on the boolean value. Check this Loom video and let me know if I missed anything. ☺️

arturosanz

@Liz Anaya you know what happened? I have two boolean fields in a table. Both are setup as nullable. So in theory, when I add a new record to the table from the Xano interface, both fields should default to null. However, from some strange reason one of those fields defaults to false instead of null. I assumed that both fields were null until I click on the check box. That's why I got confused when performing the queries. I removed the field that was creating the problem and created it again and now everything is fine. Thanks.

Liz Anaya

@arturosanz I'm glad to hear everything is working. 🙌 Thank you for flagging this stuff for us! If you encounter any other issues, please let us know.

arturosanz

@Liz Anaya I think there is an issue with the diff and diff_assoc array filters when dealing with arrays of objects. However, the intersect and intersect_assoc filters seem to deal with arrays of objects very well.

Regarding the diff, diff_assoc, intersect, and intersect_assoc filters, I assume that keys are the array indices and values are the objects pushed into the array.

Take a look at this example. I've applied the diff and diff_assoc filters to two arrays, user.adult_id and remove_adults and saved the result in var_1. The output shows the three arrays for you to see everything.

The example above is correct.

The example above is incorrect. var_1 should be…

var_1: [{user_id: 2, goal_id: 1}]

The example above is incorrect. var_1 should be…

var_1: [{user_id: 3, goal_id: 2}]

Try to replicate it and tell me what's going on.

Liz Anaya

Hey @arturosanz! 👋

I just looked into this, and I am also getting an unexpected output. There are two possibilities here: there is a bug with the diff, diff_assocfilters, or it is unclear on the docs how these are supposed to work 😅. I'm checking on this and will get back to you!

Liz Anaya

@arturosanz I got the scoop on how the diff and diff_assocfilters behave - both diffs only check one dimension of an n-dimensional array. The diff and diff_assocfilters would not work for this use case. We certainly need to update our documentation. 😅

Also, a quick bit of information: Filters are wrappers around PHP functions, so if you are ever interested in diving deeper into how they work, you can Google "[the filter] + PHP."

https://www.php.net/manual/en/function.array-diff.php

https://www.php.net/manual/en/function.array-diff-assoc.php