Use of satellite data types & syncing data

Need help Database
1

I am reading HOW TO BUILD FAST, SCALABLE APPLICATIONS IN BUBBLE by Petter Amlie and the section on the Database has sparked a revolution in my thinking. It’s been great having a resource like that available.

I’m in the process of putting the Satellite data types into action in my app - breaking apart my Product into Product-search and Product-container.

I understand the concept (I think) of using Search Data Types to keep those pages as lightweight as possible with the lightest and least number of fields as possible. I also understand offloading weight into the Container Data Types, knowing there’s a “goldilocks” balance of trying to make a product detail page as lightweight as possible so it loads quickly but also having the right number of fields and a certain weight to those fields so as to give the user the context and depth needed to make a decision.

The part I don’t truly grasp is how you keep the data synced between the satellite data types.

How would I go about setting up my workflows (or backend workflows) so when a User clicks on a product of data type “Product-search” it sends them to the correct product detail page that’s of data type “Product-container.”

Is that even correct thinking to have the product page be of data type “product-container” or would I use the “product” data type?

I’ve read the section in the book and his article on the topic of “syncing data” and it’s just not clicking yet.

I am still in need of an aha moment here. Thanks in advance for pointing me in the right direction!

2

If by ‘synced’ you just mean connected, then just have a connecting field on each datatype of the type of the other…

Then, to use your example, when a User clicks on a Product-search item in a RG, just send them to the Product-container type page and ‘send’ the current cell’s Product-search’s Product-container.

If you’re using more than 2 datatypes for the product, then just keep them all connected in a similar way.

If by ‘synced’ you mean how to update any fields that both datatypes have whenever one or the other is modified, then obviously you’ll just need to make sure you update both datatypes…

I.e. if both datatypes have a ‘Product Name’ field, and you (or another User) change the Name value on one, be sure to update both datatypes accordingly - you can either do that in the same workflow (my preference) or you could use database triggers to update connected datatypes.

2 Likes
3

Thanks as always Adam. I went into the “product-container” record and realized my “product-search” field was blank. I updated those two connecting fields to be “unique id” and after linking them its working as desired. Next step is to add the workflows to create / update those records and I think I grasp those steps now too.
THANKS!

1 Like
4

Hi @jones.joshua.d

as for example for a simple product catalogue:

Table: Product Data (in the book “data container”)

  1. Name (text)
  2. Code (text)
  3. Price (number)
  4. Description (text)
  5. Image (image)
  6. search_index (Product Search Index)

Table: Product Search Index (in the book search data)

  1. data_id (Product Data)
  2. search_text (text)
  3. search_name (text)

Both tables are related to each other - I personally user a search_text field additionaly for natvie bubble search (so I basically put there all keywords I would like)

And then by keeping in sync Peter suggest using database triggers

So if u set the db trigger - everytime when thing is edited it will also make all the changes in the Search Index (which ofc you have to setup in the backend workflows)

1 Like
5

This is a great addition @Guru - thanks! I hadn’t thought much about the use of 'search_text` fields but you’ve got me planning on how I’ll implement them.

1 Like
6

Hi all, great thread!
I’m also going through the book and need help understanding db in bubble.
I’m building something very similar and what I’m doing in RG is displaying a search_type with its fields. On search_type, I’ve added data_container as a field and I’m trying to display in that same RG group some values from data_container but it doesnt work.

So basically the “syntax” looks like following: Parent group SEARCH_TYPE DATA_CONTAINER field.
Privacy rules are ok, I’ve made it publicly available.
Can someone help me understand why this isn’t working?
Thank you all!

EDIT: could it be because I’m setting to SEARCH_TYPE on RG level? So when I create a group and set it to DATA_CONTAINER, server doesn’t send the data because of the above mentioned?

7

FYI, when you guys have questions for @petter regarding his excellent books, you should ask him directly! He’s been extremely helpful

Given Bubble’s new WU paradigm, I am hoping @petter can please update his book because I suspect satellite data types will become even more important.

Also @jones.joshua.d an alternative way to sync your data (beyond @adamhholmes suggestion) is to use database trigger events – however I think the database trigger will add 0.05 WUs to the action, something to consider

1 Like
8

Hi,

Sorry to post here some 2 years on, fully understand if no reply is received.

Probably articulating this as much for my own sake & the benefit of any others suffering from the same blind spot. I’m pretty sure I’ve just been hit between the eyes by a diamond bullet.

The nuanced piece missing from my understanding of the “satellite” concept was hidden from me by the long held belief that data duplication of ANY sort was the cardinal sin of DB design…but hey, it’s a bold new world in Bubble.

So, to be sure that I’m sure…

(Please correct me if I’m wrong…anyone!)

…in the Product Search Index table I’m assuming your data_id is the unique ID of the related Product Data record?

So, the other fields are TEXT representations of whatever is needed to fulfill the purpose of the search (e.g. truncated fields, etc.) & ARE NOT data pulled from related tables?

In order for that to work then the subtle point of significance that I’ve missed (i.e. the diamond bullet) is that the simple referencing of a unique ID of a related record in the Product Search Index table DOESN’T actually pull the entire related record (thereby bogging down processor capacity).

But in fact ONLY pulls the ENTIRE record if I call one or more of the related record’s field contents (which I wouldn’t need to do if the satellite search table fulfills its requirements)?

Assuming the above is correct then the data_id is simply the connector used to know which related record to call when you do need to retrieve any necessary fields for some data heavy operation such as editing the parent (or related) record, etc.?

Wow…seems so obvious now I articulate it, providing of course I can overcome the involuntary twitching & eye spasms every time I instruct Bubble to duplicate fields in existing tables.

Guess it can’t be any worse than Catholicism’s insidious indoctrination…I eventually got over that (twitch), mostly.

So the data light text duplication of any field is well & truly compensated for in performance gains (i.e. load speed) compared to dragging all related data down to build a multi-table RG for whatever purpose…YES?!

God I hope I’ve finally got this right in my head (twitch)…

9

Would it be correct to assume that all the above (using satalites) would be redundant if bubble allows users to only pull the required fields down the pipe when performing searches?

10

Agreed…that appears to be the obvious solution. I heard Petter say in an interview that Bubble had been contemplating this for some time but when it does finally roll out he (& the interviewer) seemed to be of the believe that the selection would be automated & out of the hands of the developer.

Better than the status quo at least…

1 Like
12

Hi @alexnferris , yes you are correct here. The relation is just an unique id of an elements - so it’s not that it “downloads” everything on the start. Thanks to this reference you don’t have to do a search for another element in the other table - you have it already at your disposal - so you can get item’s item etc.

In the current scenario it helps to save WUs. Also one point with that sattelite data. This is a concept created to overcome bubble limitations mostly. If you use normal backend like Xano you do not have such cases because you can simply return what you need.

Bubble always returns complete table - you can play with privacy rules to optimize this further but it’s kinda again a workaround in my opinion.

Cheers.

13

Hi Guru,

Just wanted to give you a belated thanks for the reply. Only just saw it…sorry.

Thanks mate, sincerely appreciated.

1 Like