Search of a blank entry will return all elements

Hey guys,

This is a bug that is connected to another forum topic Recovering Lost Data - HELP. I had created a button that would delete some elements based on a search. In this case I was creating a button to delete a payment that was connected to an invoice. The payment and invoices share a common invoice #. The button was in a repeating group of invoices and the button would search for all payments with the same invoice # as the current cell and delete it.

I have replicated this list in the forum app on the “blank element search” page (https://forum_app2.bubbleapps.io/version-test/blank_element_search?debug_mode=true)

It turns out that some of my invoices had blank invoice numbers. If the current cell’s invoice had a blank invoice #, then the search result would return ALL payments, even the payments that have an invoice number! As a result I have now lost all payment data on my app!

Can you check if this is a bug? I’m thinking others could easily make this mistake. Also is there a way to recover lost data? I know I can revert to a previous upload, but I don’t believe that recovers live data, just does a launch of that version without changing the live data.

That’s by design, when a value for a constraint is empty we ignore it. Most of the time it’s a better way to search, for instance searching for apartments with a price under an empty price should return all of them.

When you want to perform data admin stuff like this, I very strongly suggest displaying data in a repeating group first and then delete the list. Otherwise it’s quite risky, as you experienced.

2 Likes

Ok. I’m starting to toy with the idea of never deleting data. This would allow for you to recover items and revisions similar to the way dropbox keeps a history of files or you guys keep a history of updates. Just changing it to active or inactive and then having a trash can area for data that can be deleted if need be.

1 Like

How do you set the state of active/inactive ? With a Boolean for example?

yeah, a yes/no boolean on the element. Instead of deleting the element, you would be changing the boolean. Then search parameters would either search for active or inactive elements. I would have to change nearly all my workflows, but it would prevent deleting as an action.

1 Like

Deleting things is fine, deleting a whole list is dangerous

The bug just overwrote my whole database :frowning:

I would call it a bug, because it goes against the logic:

If I say: Seach for Users with the constraint user_email = Valuexyz and by accident the valuexyz is empty the search simply selects all users than it clearly goes against the logic because all other users have mails but are selected anyways. They should be only selected if their user_emails would be empty.

Would strongly vote for changing that “feature”.

2 Likes

It’s a bit more complex than that. Let’s say you have an airbnb-type search. if the max price is empty, we don’t return anything? that would be weird. We have to make a decision there, and it seems the current system is more flexible for most use-cases.

(And as I said earlier, deleting a list of things is a very dangerous thing to do)

3 Likes

I dont want to discuss too long, but thats when you should use default values? I dont delete them, I change them. At some point I need to change the status of my basket from “reserved” to “payed”. And since i dont know how many items there are I somehow have to find them…

Anyway the = sign is pretty misleading here. It does not align with the usual programming/logic understanding. Took me a while to discover the problem. “Solved” it now (hopefully) through assigning a default value in the specific field to make sure it is never empty.