Much appricided
STUDY CASE: I have 300 drivers, each one has more than 100 drives per month. So, it will be 30,000 rows.
Much appricided
STUDY CASE: I have 300 drivers, each one has more than 100 drives per month. So, it will be 30,000 rows.
It still works above 25000
25.000 chį» lĆ sį» į»©ng dį»„ng chįŗ”y mĘ°į»£t mĆ hĘ”n
As long as you use row owner wisely you should be fine
Geat, thanks
Hi @PabloMFalero ,
Do you mind explaining what you mean by this.
I have a similar concern with my App (Food delivery App) although it is still far from reaching the limit, I would like to know how to use the Row Owners to extend the āLifeā of my row limit.
I do have Row Owners in my user profile table but beyond that table, is there another way I can use the Row Owners to my benefit in terms of this limit?
Thanks in advance
I guess that is different in every app, in terms of how public your content is. @Mark_Turrell can probably provid you with a great example of exceeding 25k rows, although his app is probably the most complex app ever built in Glide.
All this to say, that the more row owner w you can apply the better, as only the rows that you own will be downloaded
Can you remove rides from the sheet once they are a few days old? Why do you need to keep old rides in the sheet?
Iām not 100% certain how your app is structured, but as an example you could apply row owners to the rides table, assuming that a driver only needs to see their own rides? In that scenario Glide will only download the rides for the logged-in driver i.e. 12 x 100 = 1200 for an entire year.
@david is there a way to automatically remove old records in Glide table or is this done manually? Curious how you would recommend going about this.
You should think about architecting this so your app only references what it needs to, when it needs into.
row owners - so the users of your app only see their own data (if by email, then a driver would see their own profile row, plus their own ridesā¦. So the app would be delivering only hundreds of rows to a device)
a driver app and a user app - use the same GS or Glide tables, but separate functionality
offload old data to another system - glide tables have an issue that you canāt really manage them (hard to delete in bulk, etc). Do you might have a glide table to temporarily store active rides, and when a button is pressed to end a ride (for instance), you copy that row to a Gs sheet, and then delete that row in the GT.
You could then retrieve the GS info with some search techniques in GS and Glide (so you are not referencing the entire ride sheet)
use integromat (best) to move data about and do tidy ups automatically
Just some ideas!
I created a request for this a while back:
Butā¦I recently had another thought about this. Itās not automatic and would take a little bit to set up, but I think a person could set up a single relation that gets the oldest row (prior to a certain date), and then add an action in a custom action somewhere in the app to delete the row through that relation. So you might have a custom action to show a detail screen, but you could add an additional action that would delete an old row as well. The userās would still trigger the action, but the more they use the app, the more it would self clean the data by deleting old and expired rows.
Thatās an interesting ideaā¦
My client want to keep records
In the app? Can they have the records in a second Google Sheet?
Yeah, I offered this solution to the client.
I will use some of @Mark_Turrell ideas (: thank you very much all
here is the sample of free glide app using 163,819 rows!
It would be very simple with Integromat
Hi Gideon,
How did you solved it?
Thank you
Send to a different GS the rows with Make automation