Array Diff Filter
Hi all,
I have run into some trouble with the array diff filter. I am comparing results from two different tables and trying to use the array diff filter to remove the duplicated results. It removes the duplicated result but also removes keys & values from another. I'm wondering if this is a bug or am I not using this for the right purpose? Screenshots attached. Thanks in advance for the help.
As you can see in the screenshot above, "Table #2" only has some of its keys left whereas the rest of tables have all their keys. The diff removed the entire "Table #6" as that was what was matching in reserved tables compared to tables. Just not sure why its removed some of the keys from "Table #2" as I do not expect this to occur.
Answers
-
What do the results from tables look like? I like to use stop-and-debug in this situation. Add below #1. Utility functions -> stop and debug. Have it output "tables". Make sure table #2 has those other keys in the original list. Share the screenshot if you can - could help us unstick you!
-
Hi @Ray Deck
Thanks heaps for getting back to me quickly. I love the stop & debug feature. It has helped me out a lot in the past. See screen shot below. The tables query lists ALL tables. The reserved tables query just lists reserved tables. In this example, from what I understand about the array diff feature is that it should have just removed all values & keys from "Table #6" as they should be identical, nothing from "Table #2".
I've copied the full results from tables, reserved tables, and available tables below to help out a bit more.
{tables: [{id: 2,
created_at: 1667529880037,
name: Table #2,
occupies: 2,
company_id: 3,
table_status_id: 2,
created_user_id: 0,
updated_user_id: 2,
deleted_user_id: 0,
updated_at: 1667552352141,
deleted_at: null
},
{id: 4,
created_at: 1667529904621,
name: Table #4,
occupies: 4,
company_id: 3,
table_status_id: 2,
created_user_id: 0,
updated_user_id: 6,
deleted_user_id: 0,
updated_at: 1667555130020,
deleted_at: null
},
{id: 3,
created_at: 1667529895537,
name: Table #3,
occupies: 2,
company_id: 3,
table_status_id: 2,
created_user_id: 0,
updated_user_id: 2,
deleted_user_id: 0,
updated_at: 1667557315755,
deleted_at: null
},
{id: 9,
created_at: 1667529949617,
name: Table #9,
occupies: 20,
company_id: 3,
table_status_id: 2,
created_user_id: 0,
updated_user_id: 0,
deleted_user_id: 0,
updated_at: null,
deleted_at: null
},
{id: 7,
created_at: 1667529932235,
name: Table #7,
occupies: 8,
company_id: 3,
table_status_id: 4,
created_user_id: 0,
updated_user_id: 0,
deleted_user_id: 0,
updated_at: null,
deleted_at: null
},
{id: 5,
created_at: 1667529913533,
name: Table #5,
occupies: 6,
company_id: 3,
table_status_id: 2,
created_user_id: 0,
updated_user_id: 0,
deleted_user_id: 0,
updated_at: null,
deleted_at: null
},
{id: 8,
created_at: 1667529940239,
name: Table #8,
occupies: 12,
company_id: 3,
table_status_id: 2,
created_user_id: 0,
updated_user_id: 2,
deleted_user_id: 0,
updated_at: 1667561229121,
deleted_at: null
},
{id: 6,
created_at: 1667529921322,
name: Table #6,
occupies: 8,
company_id: 3,
table_status_id: 2,
created_user_id: 0,
updated_user_id: 2,
deleted_user_id: 0,
updated_at: 1667628004125,
deleted_at: null
},
{id: 1,
created_at: 1667448375431,
name: Table #1,
occupies: 3,
company_id: 3,
table_status_id: 2,
created_user_id: 2,
updated_user_id: 2,
deleted_user_id: 0,
updated_at: 1667636842057,
deleted_at: null
}
],
reserved_tables: [{id: 6,
created_at: 1667529921322,
name: Table #6,
occupies: 8,
company_id: 3,
table_status_id: 2,
created_user_id: 0,
updated_user_id: 2,
deleted_user_id: 0,
updated_at: 1667628004125,
deleted_at: null
}
],
available_tables: [{created_at: 1667529880037,
name: Table #2,
updated_at: 1667552352141
},
{id: 4,
created_at: 1667529904621,
name: Table #4,
occupies: 4,
company_id: 3,
table_status_id: 2,
created_user_id: 0,
updated_user_id: 6,
deleted_user_id: 0,
updated_at: 1667555130020,
deleted_at: null
},
{id: 3,
created_at: 1667529895537,
name: Table #3,
occupies: 2,
company_id: 3,
table_status_id: 2,
created_user_id: 0,
updated_user_id: 2,
deleted_user_id: 0,
updated_at: 1667557315755,
deleted_at: null
},
{id: 9,
created_at: 1667529949617,
name: Table #9,
occupies: 20,
company_id: 3,
table_status_id: 2,
created_user_id: 0,
updated_user_id: 0,
deleted_user_id: 0,
updated_at: null,
deleted_at: null
},
{id: 7,
created_at: 1667529932235,
name: Table #7,
occupies: 8,
company_id: 3,
table_status_id: 4,
created_user_id: 0,
updated_user_id: 0,
deleted_user_id: 0,
updated_at: null,
deleted_at: null
},
{id: 5,
created_at: 1667529913533,
name: Table #5,
occupies: 6,
company_id: 3,
table_status_id: 2,
created_user_id: 0,
updated_user_id: 0,
deleted_user_id: 0,
updated_at: null,
deleted_at: null
},
{id: 8,
created_at: 1667529940239,
name: Table #8,
occupies: 12,
company_id: 3,
table_status_id: 2,
created_user_id: 0,
updated_user_id: 2,
deleted_user_id: 0,
updated_at: 1667561229121,
deleted_at: null
},
{id: 1,
created_at: 1667448375431,
name: Table #1,
occupies: 3,
company_id: 3,
table_status_id: 2,
created_user_id: 2,
updated_user_id: 2,
deleted_user_id: 0,
updated_at: 1667636842057,
deleted_at: null
}
]
}
-
@Tim McIntosh yeah, looks like it's a bug. @Michael Udinski may be you want to look into it
-
Thank you @nocodetalks. Let me know what you think @Michael Udinski.
Thanks all for your help so far.
-
It seems like you are applying this thoughtfully and it might a a bug in the product. But I can also see how you accomplish this with a small loop instead of the filter that would get you around the situation. Make a blank array of available tables. Then iterate over all tables and see whether the id of each table is in the list of reserved tables. If not, add it to available tables. It’s a few lines to maintain momentum.
we work issues like this all the time on our daily statechange.ai office hours. If you’re still stuck later today, our next is at 6p EST / 2300 GMT, and after that 7a EST / 1200 GMT on Tuesday.
-
@nocodetalks really tough to call it a bug without seeing what's going on in these queries but surely is possible
@Tim McIntosh I'm curious if diff or diff_assoc would serve you better here. Diff_assoc takes into account keys&values for matching. You can also use the function Array: Find All Elements to define the rules of the new array you're looking for. I'm also seeing a status_id in your JSON, this seems like it could be a quick win for filtering available tables if you have a status or multiple that signify availability... Lastly, if you do still think it is a bug please write into support with the workspace URL of the query and any inputs we'd need to test it.
-
I did try using diff_assoc but no results came back. I may have been using this feature wrong, however. I will try @Radik's solution first and if its not quite giving me what I want, I may follow up with the diff and diff_assoc. Plus raise a support bug.
Thanks everyone for their help.
-
@Tim McIntosh use the Customize response feature and unselect the column on which you are creating two array
Categories
- All Categories
- 53 ? Announcements
- 47 ? Releases
- 37 ? Welcome
- 983 ? Help! I'm a Noob
- 125 ? No-Code Front-Ends
- 633 ? Working with APIs
- 439 ? Transforming data
- 126 ? Connect Xano to ...
- 50 ?? Find an Expert
- 348 ❓Other questions
- 35 ? Security
- 22 ✂️ Snippets
- 19 ? Showcase
- 7 ?️ Xano Chatter
- 62 ? Video Tutorials
- 171 ? Request a feature
- 229 ? Report a Bug
- 19 ? Templates & Extensions
- 7 ? Feedback