please please help me understand how the detailed view works. which row does it return and how does it return that row.
I have a checkout page based on a detailed view of the orders table. its supposed to return 1 row from the table only. which matches a certain filter.
when there orderID is empty, it returns a msg that no order is in checkout.
what i am getting is:
orderID of required row is found + the order info
then i get an empty rowID + msg that no order in checkout
then again the detailed view returns the correct row
why is this happening? why is Glide not returning the first match and instead searching for more matches? what is the expected flow in such a case, i need to know to try and reduce the delay where clients get the msg ’ no order in your checkout’
The answer depends on how you got to that detail view. If the top level of a tab is a detail view, then by default it defaults to the first row in the table, unless you have filters or any sorting other than the default sheet order sorting. Also, if you have row owners enabled, then the first row shown will be the first row that belongs to the owner.
If you got to the details view from a list then obviously it’s going to be on the row of the list item you selected.
That’s the short version. You also have to consider if you got to a details view through a relation or some other means.
Based on your description, it sounds like you have an orders tab that points directly to orders table and you have that screen filtered. It should find the first row that matches that filter and display that first row details. Screenshots or better yet, a video, would help to better understand what is happening. What does the data look like? How is the detail screen set up? What does your filter look like? How are order rows created? Is this a google sheet or a glide table? If it’s a google sheet, are you using google sheet formulas to build some of your data? I suspect some sort of ping pong effect where a row is added, removed, then added again, but it’s hard to say for sure without seeing it in action.
checkout tab is based on orders table which is only 10 rows. i don’t understand what exactly is happening but i know for sure, its not returning the first row that matches and then ending the search.
or when it finds the first match something weird is happening.
What does the action look like for your checkout button? Whenever I click on it, it’s doing what you are saying it’s doing, but it seems like it’s creating a new order every time. I clicked checkout, and then back several times and now I have 6 orders. Can you also show what the filter looks like for the checkout screen?
sets column in product table when order is created
add row to orders table
navigates to checkout tab
everytime you click on it a new order is created, its a new checkout. you can delete the order manually if you cancel your order. or admin’s can delete incomplete orders.
the filter for the checkout screen is
order is not DONE
timeOrderCreated is not Empty (this is user specific column) so users get only their orders
timeOrderCreated is timeLastOrderCreated (a rollup column gets its values from the products table, time order created column)
*if anything causing a delay its this last fitler, but why do i get the correct result then a delay then the result again. as if the detail view is looping through all rows or loosing its markers while on the correct row
I just found out what is really happening. i don’t know how to fix this its internally in Glide.
the checkout button creates a new row in the orders table and then navigates to checkout tab.
(The Orders Table is a Glide Table.)
internally in the checkout tab, Glide recognizes the new rowID added !
(Although the row doesn’t appear in the glide table yet, it takes a few more seconds)
so a new row is added but not yet reflected into the glide table but Checkout Tab can see it and return its ID!
the filters of the checkout tab find this result. return it with its row ID. THENN
internally then as the row is being transformed from Glide into the Glide Table… it is lost again by the Checkout Tab. hence the filters return the 2nd result.
the glide table is updated with a new row and so the CHECKOUT re-filters the results according to the Sort and returns the correct new row again.
I don’t know if the way i phrased this makes sense
Seeing your video in your other thread, did you ever figure something out for this? I’ve studied your video above, and obviously see the problem, but I’m not sure how to avoid it. In reality, the app and the builder each contain separate copies of the database (which each sync to glide’s server), so it seems like there is a temporary sync issue. The interesting thing is that, based on how instant the new rowid is assigned, the RowID appears to get assigned by the app itself, since it’s instantly there, but it’s almost like the apps internal database temporarily loses the row as it syncs the new data to the glide server DB, then get’s it back once it resyncs. I haven’t ever noticed something like this, but I also don’t usually go directly to the details of a newly added row.
there are a few things i found out. it was taking a bit too long so I went with the idea of removing the 0 orders in checkout. Instead now i load a msg saying wait for your order to be initiated. and so users checking out don’t see the scary msg of 0 orders in checkout. it only takes a few seconds and the checkout page is ready to be fully used.
but for future note, I found out that this issue is only happening for signed in users. This doesn’t happen for guest users of the app. it is also not happening in the Glide editor itself. Only in instances of the app opened elsewhere.
i’m not sure this is not appearing in the glide builder. i think it is but with way less delay.
maybe because the rows have user specific columns, or the filter has user specific columns. and since a user is signed in, Glide does some extra verification that its the correct user to access this data? but then why does the rowID appear immediately upon creation? maybe a small bug?
in my app guest users also access user specific columns, but maybe Glide considers them as guests and hence doesn’t do the extra layer of account verification before granting users this access to user specific data?
i’m guessing here user specific data is based on user session? so if a user is not signed in and uses an app, then signs in and uses the app from the same PC, he will get both the data showing at that instance.
however if he signs in on a different device, the will only see the data he accessed while signed in on the previous device. a bit vague for me what really is happening.
Any advice on this its a very weird issue… possibly a bug related to user specific columns & signed in users.
Glide filter for a detailed screen is returning 1 row then returning another row before coming back to return the right row again !!
@SantiagoPerez
Dear Santiago, if you have time please have a look at this “bug” or maybe issue within Glide. I assume one client has contacted you directly to explain the issue. Here are some major findings we have found and a video attached. I advice you read Post #6 and down.
Would highly appreciate your advice here, any chance we can get this fixed or get around it?
Hi Santiago the issue with custom carts and checkout is there are so many columns involved time etc… let me try, I will try to copy the app and delete the unnecessary tabs. I will as well put comments in the top of the tab as in the video so that you can clearly see which row ID is being returned in the screen. would you think that would do ?
Problem only occurs for signed in users. I have added a few notes on top of checkout tab that might help you see what is happening.
Sign In and give it a try.
The weird thing is that the detail screen in the checkout tab returns the correct row (first match) then it loses it !! and returns and finds it again !
