Creating entries in database from cells in a repeating group

hi.luisacosta · 2024-12-10T15:17:29.389Z

Pretty much the only way to do this is using the Orchestra plugin. It’s going to feel a bit odd at first but after a while you will be able to use it easily!

If you are good with JSON and API’s you could do this using just text but it would take longer and be harder to maintain in my opinion.

bek · 2024-12-10T16:50:49.537Z

Hey @samir.elkaddouri79, as mentioned above, to run workflows on each individual cell in a repeating group, you gotta use the Orchestra plugin.

However, you can get the same end result if you modify your build.

Rather than relying on the Next button to be the trigger to create the database entries, create them before hand in your database, and have the Next button be the validation step.

Add a draft field (boolean or date) for your Loan datatype
– if you go with boolean (yes/no), make it yes by default
Enable auto binding for type of loan, monthly repayment amount, and first repayment date (both under privacy settings and each respective input field)
When the user lands on your form, run a backend workflow to auto create all 6 possible values for the user, where draft = yes
When the user selects a value from your dropdown (0-6), display the appropriate # of loans that were created above
Because you enabled auto binding, as the user makes changes for each cell, it will get updated in the backend
Finally, use the Next button as the trigger to flip draft = no for each of the cells in the repeating group (this way, if the user selected 4, then only those 4 Loans would get moved to draft = no).

hanan1 · 2024-12-11T04:39:06.737Z

Cool! This is similar to how I would do it, but I wouldn’t use a repeating group.
Since it’s a fixed 0-6 choice, I would use 6 groups and show/hide based on number of loan selection and create them in bulk as steps in the workflow when user clicks next, this may be less scalable but I think for a fixed number it is easier, does not backend workflows or plugins and it saves space by not creating 6 drafts for each user. literally takes minutes:
ScreenRecording2024-12-11at9.10.02AM-ezgif.com-video-to-gif-converter

ihsanzainal84 · 2024-12-11T05:27:03.501Z

That’ll cost a pretty penny with all those unused records created in the DB. Another penny for every deletion of those records to.

OP, @hanan1 posted a solution that does not use RGs hence making it easier to grab answers. You can store them in states first without meddling with RG states.

bek · 2024-12-11T05:36:51.876Z

Each creation is what, 0.5 WU? So ~4WU for creation and deletion.

If 1k WU = $0.30, then one full run costs ~$0.0015

ihsanzainal84 · 2024-12-11T09:44:37.398Z

I know. Pennies. Many a pretty penny.

pieter.vanrensburg · 2024-12-11T10:23:45.456Z

Before the WU based model this was a viable option. In fact, I still use it when I’m absolutely guaranteed those records will be used. However, when we have 100 users each do this 10x per day, you get a cost that most would consider material. Now apply the same coding method in 20-50 other places in your app and it very quickly becomes unprofitable. We should never touch the DB unless we absolutely have to.

shane.holohan1 · 2024-12-11T10:59:40.866Z

I’d suggest that there’s a better solution from both a user perspective and simplifying the WF needed.
As a user it’s more intuitive to add one loan at a time.
User clicks on “Add Loans”
One loan data type is created (can be “draft” as described by @bek )
Loan data type is added to users “Loan List”
First line of RG is then visible (RG dynamically loads all loans in “Loan list”)
Fields in RG autobind on Loan data (or when confirmed by button click)
Then user clicks “add another loan” or “finish”
Add another loan creates a new “loan” and adds loan to “loan list”
When all loans are added, clicking finish changes all loans “draft field” to “no” - using “make changes to a list of things”

boston85719 · 2024-12-11T11:05:51.841Z

Best way to do this is to take the values from the RG cells and translate them into JSON. Can use a paid plugin called JSON assistant to do this (maybe others but I use that one)…then need to setup the API connector to work with bulk update for your data type of Loans…once the user is ready, can send the JSON through the API call to bulk create as many loans as the user created. Costs less than any other method mentioned, and you can allow a user play around with the RG and loans as much as they want without touching the database, and when they are ready, they press submit button and you run the API call.

shane.holohan1 · 2024-12-11T12:50:52.773Z

Just on observation from a non-tech no-coder. I don’t see the point in using JSON and API when there’s a genuinely no-code option. Surely the whole point of Bubble is to only use code-based tools as a last resort? I get that for code-savvy builders there are often easier solutions (for them) using some code. But the downside is that the built in error checker can’t check the code based pieces. For me the robustness of Bubble’s error checking (and prevention) is why I use it.

boston85719 · 2024-12-11T15:32:23.724Z

JSON is text, not code. It’s just simply formatted in a particular way. API is not code it’s using Bubble built in API functionality of every bubble app and the api connector by bubble. Bubble manual explains how to use it very well.

I don’t code. I’m nontechnical also. But ultimately the point of using the text in JSON format and API connector is to build a better, more efficient and lower cost to run application.

hi.luisacosta · 2024-12-11T15:48:01.642Z

Basic JSON & API skills will supercharge anyone’s bubble use! Would 100% recommend.

bek · 2024-12-11T16:11:32.341Z

Kind of a meta ramble, and beating a dead horse here…but its really concerning to see the mental gymnastics made in the sake of saving a few WU (even at scale).

Obviously a side effect of WU introduction and devs wanting to min/max WU usage, but where do we draw the line in building spaghetti code (that takes longer to build and longer to debug later) for the sake of WU?

At what point do we ask “is what I am building profitable via bubble?”

boston85719 · 2024-12-12T03:45:02.152Z

I think you posted in wrong thread. There is an active thread where people are discussing saving WUs and the pricing structure. This thread is about optimal way to get data from RG cells into DB

doublejay · 2024-12-12T05:29:45.008Z

I use the Floppy plugin to store inputed values on page and then pass those on to backend workflow to create DB entries when submitted.

Don’t understand why bubble doesn’t support this natively. Seems like a very common use case.

shane.holohan1 · 2024-12-12T11:20:21.051Z

Code is also just text formatted in a particular way I don’t doubt that JSON and API creates other perhaps more efficient ways to do things. I do this myself (but I’m four years into Bubbling). The big reason not to do that, until you really have the skill to do so, is Bubble’s error checker won’t pick up any resulting bugs. And that is a big issue for people who aren’t long at Bubble.
And for this particular problem I’d humbly suggest that JSON, API and Bulk Data Upload is a sledgehammer to crack a nut.

shane.holohan1 · 2024-12-12T11:31:59.542Z

IMO the reason for this is the fundamental design of Bubble. It’s an existential aspect of the system. The DB is live, in the sense that changes to the data are immediately visible to the user. There’s no getting data from the backend to display in the frontend. So why would you ever want to store data locally when you can immediately save it and have access to that saved data? And run WFs based on changes to the data. For things that don’t need to be saved we have states. Also states for capturing data at a point in time and passing data between elements.

hi.luisacosta · 2024-12-12T15:35:33.647Z

That’s an oversimplification. Yes code is formatted text but with many rules syntax and hidden functions.

JSON is very simple and nothing like coding lol

bek · 2024-12-12T16:08:39.886Z

Nope, posted in right thread.

boston85719 · 2024-12-13T07:48:38.550Z

shane.holohan1:

sledgehammer to crack a nut

I’ve seen others on the forum use this same saying about other things as well…in this case, no it is not. It is more like using a nail gun instead of a hammer, where the nail gun is good to use for all situations, and in those where there are a lot of nails it performs infinitely better than that of a hammer.

shane.holohan1:

The big reason not to do that, until you really have the skill to do so, is Bubble’s error checker won’t pick up any resulting bugs.

No, one reason to do it before you have the skill to do so is to build the skill to do so…you don’t have experience until you have experience. Plus, the error checker in the API connector will alert you to issues when you initialize, and in the logs you will see the error for failed workflows when you run the API call and there is an issue with the setup. Additionally, if using a plugin for JSON the issue checker will alert you to issues and the debugger will alert you to issues as well, just like any other built in functionality from Bubble (API connector) or well built plugin.

shane.holohan1:

So why would you ever want to store data locally when you can immediately save it and have access to that saved data?

So as not to have to pay for WUs when it is not necessary.

shane.holohan1:

For things that don’t need to be saved we have states. Also states for capturing data at a point in time and passing data between elements.

You can do this with storing data locally as well, however, local storage is not lost when the user closes the browser or refreshes, while custom states are…so a good UX would utilize local storage instead of custom states so as to anticipate the potential a user may have computer crash or something else and when they open the app again, you can have them start where they left off, but custom states requires the user to start all over again.

Also, local storage allows data to be passed from page to page while custom states do not.

bek:

Nope, posted in right thread.

bek:

but its really concerning to see the mental gymnastics made in the sake of saving a few WU

Having to think critically is not necessarily mental gymnastics, and in this situation it is not mental gymnastics. Most of the time people on the forum use the phrase mental gymnastics in reference to WUs is in the attempt to understand the costs of things, but not really in attempts to build optimally with WUs in mind.

In the case of the OP request for help regarding creating entries in database from cells in a repeating group, using the approach of JSON and API connector, in some situations may not lead to saving a few WUs. For example, I have a client app, that gets 70,000 - 100,000 visits per month from Google. They have a form to request a quote. That form allows a user to create multiple ‘loads’ in a repeating group, the number of loads is unknown, and so they can create as many as they want, delete them and modify them all without ever touching the database until they are ready to submit their request.

If I didn’t use the JSON and API connector, the client app would have potentially users creating and deleting things in large numbers before the client app could ever potentially monetize that user.

Now, consider a simple scenario, each user creates two entries in RG…if we create each individually in the database, that is two actions of create a new thing, and the creation of a new thing, which is 2.2 WUs plus the cost of characters…for api it is 1.75 WUs…if we think 100,000 users a month, that is 45,000 WUs per month, assuming each user only ever creates two things. Its not a few WUs, and in the end, every little bit matters.

Additionally, it is not just about WUs, its about performance.

At the end of the day, I’m just offering free advice on how to build the OP feature in an optimized way. If others do not want to build optimally, that is there choice.