Here’s an example with a private only blog.
- 2 Types : “User” and “Article”.
- “Article” has one Field “readers” containing a List of “Users”.
- A Privacy Rule is set so that every “User” can access an “Article” only if the Field “readers” contains the “User”.
If I build and run a workflow that removes all reading privilege of a given “User” for every Article he/she has access to (which is the equivalent of removing the “User” element from the Field “readers” of every Article)…
(1) …Am I going to encounter problems if the workflow needs to update 10,000, 100,000 , 1,000,000 Things (rows) in the database ?
(2) Is there any limit to such operation ?
1 - Yes, making tons of change on many rows is kinda rough for the database (especially if you are talking about 10 000, 100 000, 1 000 000 rows).
2 - I had a lot of issues with bubble with modifying/creating/deleting a lot of data on “one shot”, because it’s pretty slow.
Here a solution you could use :
Instead of having an article with a fields of “users that can read the article”, each user should have a list of field called “accessible articles” referencing all articles that the user can read. With this data structure, you will remove those articles in the user “accessible articles” with the action “remove list” for this user. In that case, you will change only one data which will be much faster than the other way around.
But of course, if you have to remove this item (without deleting it) from 10 000, 100 000, 1 000 000 users, you will be facing the same problem as mentioned in your post.
Thanks Benoit for your insight.
I’ve been considering the “accessible articles” way you proposed, but unfortunately I’m 100% sure that Users will need to have access to more than 10,000 Article in a very near future. And because there’s a limit of 10,000 element per List Field, I believe it won’t work.
Any Idea how I could go around the 10,000 list element limit in this scenario ?
Are you sure there is a limit of 10 000 items?
In my database I have a field that has more than 12 000 data (array of numbers).
I have store more than 19 000 (numbers) and it was working well. Are you sure there is a limit of data in a ‘‘list of field’’? I believe the data is saved as a simple ‘‘text array’’, which is why it’s so fast to “set list” in the database.
Another way would be to use the tool box plugin “to run javascript code” and store the data as a JSON text file in one of your user field. For complex and heavy data, I’m using this approach to manipulate a lot of data without having to create/delete/modify many rows/fields. However, this approach requires that you understand some basic javascript coding.
Thanks again Benoit, I really appreciate the help.
Here’s a post with the 10,000 list item I’ve mentioned.
To give you more context, the solution I’m looking for needs to work with Algolia and Bubble Privacy Rules. In the example above, I’ve used the Type Article for simplicity, when I should have really talked about a Type “Message” instead. Picturing Slack.com with full message text search (fuzzy search) is a good example of what I’m trying to achieve.
I’m thinking about your idea with a JSON file and all the complexity it would involve, especially with Algolia.
At this point, let’s say I’m trying to rebuild slack with a role management per channel and a fast full text (message) capability.
-
Would a JSON file per User, holding all the roles for every Message, work with Bubble Security Rule et Algolia ?
(assuming I’ll build a custom bubble plugin to make it work.)
-
Is there a way to do it without using a JSON file ?
Just looking for the best path to dig deeper…
Unfortunatly, I am not familiar with Algolia, so I can’t help you with that sorry.
As for the privacy rules, if you give access to the ‘‘json data’’ you won’t be able to private the data partially (except if you add some privacy in the data of the json file that will be filtered when your ‘‘run javascript’’ extract data from it).
As for using another way than the JSON file. I don’t know if there is another one, some more experienced user may have found another/better solution.
