HubL "in" operator and HubDB Select field results not working as expected

[elmo]

I think I've found a bug, or at least an oversight, in how HubL  in operator handles the sequences returned by the function hubdb_table_rows. I have created a table which has a column named "type" and is of type Select. So, when I get the rows back, the row.type.id should return an integer, based on what choice is set.

Then I'd like to use the in operator to find if that value is one of certain values. E.g., the ID could be any ranging from 1 to 6, and I'd like to do something if it's 2, 3 or 5. The workaround is naturally if (..) or (..) or (..), but it's not a good and easily maintainable coding practice.

The problem is that the in operator does not work. Even if the row.type.id is a number, the following code always returns false:

{% set row = hubdb_table_rows([my table id], content_query)|first %}
{% set choices = [1,2,3] %}
{{ row.type.id in choices }}

It is at least very unintuitive. Even the row.type.id is number returns true. Also, the following both return true (assuming the type in the table is the first choice):

{% set x = 1 %}
{{ row.type.id == x }} {# true #}
{{ x in choices }} {# also true #}
{{ row.type.id in choices }} {# still false #}

So, the [field].id equals to an integer, is of type number, but with the in operator it is not found in the sequence that contains numbers. Based on the results I'd say this is a bug. Probably internally the in operator somehow sees the [field].id as some other type than integer, hence not working. But I'm not sure.

It also doesn't help if I try "typecasting" (if there's such a concept in HubL/Jinja) it with the round filter, i.e.:

{% set rounded = row.type.id|round(0, 'floor') %}
{{ rounded in choices }} {# still false #}

However, if I try making a sequence from the row.type.id, then the in can find that in the sequence:

{% set seq = [row.type.id] %}
{{ row.type.id in seq }} {# this is true #}

So, somehow the in operator works in this case. This somewhat reinforces my opinion that even though HubL claims the [field].id is of type number, it doesn't typecast it correctly in this case.

I made a test page to demonstrate the problem: http://1797693.hs-sites.com/hubl-in-operator-test

[tjoyce]

@elmo - My initial thought is that "type" is some kind of reserved word but (1) it shouldn't matter if it's an object child (2) I couldn't find any documentation on jinja2 reserved keywords (so, that's probably not it). I am curious what the output of the following code is though: 

{{row.type|pprint}}
{{row.type.id|pprint}}

---

tim@belch.io | forms.belch.io | Design your own Beautiful HubSpot Forms; No coding necessary.

Drop by and say Hi to me on slack.

[elmo]

Hi again @tjoyce. Just pinging you that the post is visible again - thanks for your reply yesterday. Yesterday I edited one typo in the post and the forum somehow flagged it as spam. Probably because of the link, but somehow only after the edit, not the post. Took a day to get it unflagged. *sigh.

[elmo]

Thanks for the suggestion. I now added them on the test page. row.type.id returns (Integer: 1), so at least nothing there to indicate why it shouldn't work.