Actions log - best practice

Ask for Help
1

We keep an actions log for every action a user performs on a row in the table.

Currently for every action tracked this requires an extra update (set column)

This is how it works when a user triggers an action we want to track in the log

  • Set column, sets the necessary action values, then there is user specific columns set to describe the action and the timestamp.

  • here there is a temporary template column that joins the latest action with the previous action history as temp actions history

  • the last update is a set column that changes the value of actions history log to the temp actions history (which includes the latest action)

Is there any way we can get rid of the last step and do it all in one set column ?

3

having a separate table for actions would be ideal but not possible at all. We have thousand of rows and for every row there are tens of actions. The aim is to keep the actions log within the row.

4

Just a thought - but, if you are using Airtable, you could send a Webhook to Make (or similar) to add a row to a separate Airtable table (which does not sync to glide) with the log info you need.

Would that help? I guess the same could be done with google sheets?

1 Like
5

Hi! As i understand you have two set column in one action
First set to user specific column which not counted as update
Second is counted
Why you need One set column instead two( actually all set column must be counted as one update if all in same action)?
Also, may be, one cell can’t fit more than one million symbols and you need to check the length and cut data to arh column if exceed
Another good point: Glide announced support for 10millions rows in this year

1 Like
6

If you need to see the action log in Glide, then Glide Big Tables (coming soon) will be your best friend. If not, then as suggested above, an automation to some other database is probably the most straightforward solution

3 Likes
7

Thank you Robert. Yes definitely need to see it in Glide. Actually only need to see it in Glide. We already have it set and working since months I’m just asking if anyone got it working in 1 set column. We use 2 set column for it. One is part of the normal set column we would already be using. but the other is a bit annoying and just for the action log. considering we have thousands of actions every day thats taking up unnecessary updates.

8

To my understanding they are counted as 2 updates not one

9

Yes we don’t have much data in one cell. one row can have 10-20 updates at max. i’m more worried about the update costs

10

only need to see this action log in Glide.

11

Have a look at the below:

  • All log events are stored in the item row, in a JSON structure
  • Logs Views, Edits, Adds & Downloads.
  • A Helper Table is used for viewing the logs. This table requires as many rows as the maximum number of expected log events per item. (The template is capped at 1000 rows).
  • Works as a FIFO log, so once the maximum number of events for an item is reached, the oldest events are dropped.
  • I’ve tested it with up to 3000 log events per item. Above that, it starts to slow down.
  • So with a table of 1000 items, you can store up to 1 million log events with a total cost of 2000 rows.

The structure of the log looks like so:

{
"events":[
	{"date":"30 January 2023 at 13:24","user_id":"sNjQtnNzQ7O1aFb5cnEWLg","action":"viewed"},
	{"date":"25 September 2022 at 20:06","user_id":"xnCQ.4liQyKSsatK876XkA","action":"edited"},
	{"date":"25 September 2022 at 1:06","user_id":"xnCQ.4liQyKSsatK876XkA","action":"viewed"},
	{"date":"24 September 2022 at 23:30","user_id":"xnCQ.4liQyKSsatK876XkA","action":"viewed"},
	{"date":"24 September 2022 at 23:29","user_id":"xnCQ.4liQyKSsatK876XkA","action":"viewed"},
	{"date":"24 September 2022 at 23:28","user_id":"xnCQ.4liQyKSsatK876XkA","action":"downloaded"},
	{"date":"24 September 2022 at 23:28","user_id":"xnCQ.4liQyKSsatK876XkA","action":"viewed"},
	{"date":"25 September 2022 at 1:06","user_id":"xnCQ.4liQyKSsatK876XkA","action":"created"}
	]
}

In terms of Update overhead:

  • View: 2 additional updates (one could be removed if View logging isn’t required)
  • Add: zero additional updates. Uses native Add form with no onSubmit action.
  • Edit: zero additional updates. Uses native Edit form with no onSubmit action.
  • Download: 1 additional update.

I’m not sure if I’d consider this best practice, as to my knowledge very few people use this technique (or are even aware of it). I developed the technique for my own use about 6 months ago, and have been using it successfully in 2 or 3 separate Apps since then. It may or may not apply to your use case, but it might give you some ideas.

5 Likes
12

is there more info available on what to expect from Glide Big Tables in the community?

13

All I know so far is that

  1. they’ll hold 10M rows
  2. They’re searchable
  3. They cannot yet be aggregated (Glide’s working on it)
  4. They’re paginated when loaded into a collection
5 Likes
14

So Great Man!