Copy List of Things to A Different Table

sahmurat.ugurlu · 2024-12-29T14:04:24.790Z

Hello,

A have two tables called: A and B.

I want to create records when a button clicked for B table for each A table record. How can i do that?

boston85719 · 2024-12-29T14:59:22.795Z

sahmurat.ugurlu:

I want to create records when a button clicked for B table for each A table record. How can i do that?

I think what you are asking is how can you when a button is clicked create an entry in table A and table B…simple, action step 1 create a new thing table a and action step 2 create a new thing table b

mitchbaylis · 2024-12-30T06:03:24.307Z

it sounds like you want to

click button in b table
iterate over each item in a table and create a new item

to do that you want to click the button then schedule a backend workflow to iterate through table a’s records and then create a thing for each record (backend)

boston85719 · 2024-12-30T08:17:21.045Z

If the idea is to create record in table A for every record in table B and they are basically copies, best approach is to use bulk create API for table A and the json body is table B format as text to construct the JSON representation

sahmurat.ugurlu · 2024-12-30T10:10:54.577Z

This is exactly what i want to do. I’ll try this. Thanks a lot.

boston85719 · 2024-12-30T10:21:09.639Z

mitchbaylis:

it sounds like you want to

click button in b table

iterate over each item in a table and create a new item

to do that you want to click the button then schedule a backend workflow to iterate through table a’s records and then create a thing for each record (backend)

sahmurat.ugurlu:

This is exactly what i want to do. I’ll try this. Thanks a lot.

You will pay more in WUs for this approach instead of the approach I suggested below.

boston85719:

If the idea is to create record in table A for every record in table B and they are basically copies, best approach is to use bulk create API for table A and the json body is table B format as text to construct the JSON representation

Charges for iterating in backend is 0.7 for each schedule backend workflow (0.1 for the adding to scheduler and 0.6 for the action of schedule a backend workflow)…plus you get charged for each action of create a new thing (average is 0.62) and the creation of the thing (I think that is around 0.1). Plus you get charged for each record from table you send back as parameter list for iterating over. If you have 10 records that will be 10 first run, 9 second run, 8 third run and so on until final run is 0 records, which means you get individual data requests 55 times at a rate of 0.02 each time for a total of 1.1 WUs.

What that means is if you run this for ten records you are going to get charged around 15.1 WUs…but if you use the API as I suggested you get charged for the running of the API call action (0.6) plus the creation of each item (if 10 items and is 0.5 per than 5 WU)…so a total of 5.6 WUs; Plus iterating in backend is slower.

If you are just building something for fun, it might be fine, or just a true MVP. But if you plan to build a production app and scale on Bubble, you’ll be kicking yourself later for not building it optimally from the start.

Below is simple test from an app of mine…it is hard to discern if the total cost was 2.78 only or was it 2.78+0.71…I created 10 entries in the database. I never really see what I would expect based on the public WU pricing chart.

Screen Shot 2024-12-30 at 5.26.42 PM392×204 14.1 KB

Screen Shot 2024-12-30 at 5.26.07 PM469×108 8.65 KB

Screen Shot 2024-12-30 at 5.32.40 PM854×469 24.4 KB

The 5.05 WU in the chart makes more sense than the 2.78 in the logs since the public pricing states each item written to or modified is 0.5 WUs, so 10 items created I can understand as costing 5.00 WUs or rounded up for good measure to 5.05…so maybe the logs are just showing wrong information in terms of WU charges.

mitchbaylis · 2024-12-30T11:07:31.160Z

schedule api on list of things > goes to backend workflow to create the thing (iterates the list and runs for each item)

schedule api workflow = 0.5wu + search wu
add a new item to api scheduler = 0.1wu per item
server side workflow action = 0.6wu per item
create a thing in database = 0.5wu per item

approx 11 wu to create 10 things

bulk create is a viable alternative if you really want to reduce wu’s

unless you’re doing a lot of data copying there are more impactful ways to reduce wu costs in most apps

bulk create is also very limiting in that you cannot process each record individually - ie you can’t add multiple steps to the creation workflow and evaluate conditions etc per item. you can get around that with a database trigger I guess, but that has downsides as well (conditions evaluated every database change which can get costly)

boston85719 · 2024-12-30T15:05:44.009Z

mitchbaylis:

bulk create is also very limiting in that you cannot process each record individually - ie you can’t add multiple steps to the creation workflow and evaluate conditions etc per item.

You process these types of things when crafting the json for the bulk create api call

mitchbaylis · 2024-12-31T05:44:13.614Z

I mean for if you need to create child items, or do other logic

bulk create is fine for a duplicate but it is very limiting for create from list.

for instance I often will create things from a list of option sets - create 1 item for each option.

but there will be conditions applied so I may only want to create the option if XYZ - and those conditions may change or have multiple filters per option set - so each option needs to be evaluated, and then each option may need to trigger other things to happen - basically I rarely find a use case for bulk create other than to duplicate existing items.

and the cost savings of using bulk create vs just the schedule api on list are minimal for most apps - most wu costs are in repeating groups, searches on pages etc

boston85719 · 2024-12-31T06:05:52.893Z

mitchbaylis:

most wu costs are in repeating groups, searches on pages etc

Not really. If the app requires a lot of creation of data or modification of data, those add up quickly.

mitchbaylis:

bulk create is fine for a duplicate but it is very limiting for create from list.

Not at all in my experience. The bulk create is not limited in any way for creating things from a list. I would believe the only limitation is based on the way in which a developer can conjure up ideas on how to implement it.

mitchbaylis:

for instance I often will create things from a list of option sets - create 1 item for each option.

Awesome…then you will have a body json that is set to ‘all options: format as text’ so that you can run the bulk create off a list of option sets.

mitchbaylis:

but there will be conditions applied so I may only want to create the option if XYZ

Use inline conditionals via dynamic expressions to accomplish this

mitchbaylis:

so each option needs to be evaluated, and then each option may need to trigger other things to happen

Other things to happen being evaluating if the condition is yes or no and can be done via inline conditionals

mitchbaylis:

basically I rarely find a use case for bulk create other than to duplicate existing items.

I have found numerous

mitchbaylis:

and the cost savings of using bulk create vs just the schedule api on list are minimal

mitchbaylis:

I mean for if you need to create child items

If child items is reference to related fields, those are just the unique ID of the related field.

I find it hilarious that people keep talking about differences being minimal because they assume that everybody looks at math in the same way. Let’s take our hypothetical example of 10 items being created, via bulk create or a recursive backend workflow…bulk create costs around 5 WUs, recursive backend workflows cost 15 WUs and a schedule workflow on a list maybe 10 WUs as you pointed out…so that ‘minimal difference’ some people might say, ‘yeah, 10 compared to 5, the difference of 5 is minimal because 5 is a small number’ while others may say ‘10 compared to 5 is twice as much, so 200% greater’…I am the type that says it is twice as much or rather more importantly 200% greater, and 200% greater is not ‘minimal’ difference.

Also, it seems everybody forgets why we have WU pricing, it is because people were not building optimally and the strain put onto Bubble made it so they couldn’t carry the costs, so they made this WU pricing. So, if everybody keeps building sub-optimally, the WU pricing will increase, since there will be an undue stress on bubble systems still since people are not building optimally still.

The reason my health insurance is 50% higher in the last two years is because more people were using their coverage…the same logic can apply to an increase in WU costs if Bubble decides to increase them.

Another thing that I think is different between my consideration of WUs and what seems to be the consideration of many other devs who continuously say the differences between one approach and the other are minimal differences and nothing to fret about, I look at things as aggregates and not isolated. So add up all the differences and they can aggregate to a large total, or add up all the times something is run and the ‘minimal’ difference becomes a large difference. I personally would feel as if I am doing a disservice to my clients and students if I didn’t consider my client’s costs of operating their app and ensuring it is as low as possible, or a disservice to my students to not be able to give them an idea of all the different ways they could accomplish something and the implications of each approach, especially around costs.

You should give the bulk create another look.

mitchbaylis · 2024-12-31T06:54:13.827Z

bubble is focused on “democratizing software creation so non-technical users can build and launch their ideas”

sure you can create workarounds with custom code and calling apis to run bulk creates to reduce wu costs but for the majority of users who are building apps that scale to a few thousand users - 5 wu is not a lot and unless users are regularly duplicating hundreds of items it’s not something you need to worry about or optimize for.

to the thread owner - there are many ways to do the same thing in bubble, the outcome is largely the same.

bulk create via api using json
schedule api on a list

both do the same thing. I prefer schedule api on a list even though it costs slightly more wu. it’s easy, built in and works fine.

focus on launching and solving problems. if you find wu starts to cap out then look at the reports and see what’s chewing up your usage (it likely won’t be bulk create vs schedule api on list).

happy bubbling

boston85719 · 2024-12-31T07:50:08.870Z

mitchbaylis:

both do the same thing. I prefer schedule api on a list even though it costs slightly more wu. it’s easy, built in and works fine.

The API and bulk create is also built into Bubble

mitchbaylis:

bubble is focused on “democratizing software creation so non-technical users can build and launch their ideas”

I’ve seen others making this statement about why not to use the more advanced features of Bubble, which is fine, for most new users, they will play around a bit, make some simple things work and be excited enough to be able to build something and tinker a bit…but for those who are looking at building a more performant production app, or are professional bubble developers they may benefit from using some of the built in advanced features of Bubble.

For me personally, after building on Bubble for only 2 years, I was hesitant to investigate and utilize some of the more advanced features. I didn’t start to use the bulk create until I had been building for 4 years. Now that WUs are a thing, I’m using it a lot more now than in the past as saving WUs in every way possible can add up to savings over time…even if I save $300/year, that is $300/year in my pocket and not Bubble’s, and I personally have never been one to willingly pay more for something than I need to.

In the end, you are correct @mitchbaylis users should focus on launching, and if using schedule on a list gets them to launch faster that is great…fail fast and cheap as they say, and should the user gain traction, evaluate whether or not there is a need to alter the setup to a more performant, less costly method. And if the user is a developer, serve yourself and your clients well by taking the 30 minutes to learn the bulk create method and be able to implement it from the beginning of the build. It will improve the developer skill set (ie: increase the tools in their toolbelt) and reduce the WU costs for the client, likely saving the client a few dollars or more.

system · 2025-03-09T14:05:05.105Z

This topic was automatically closed after 70 days. New replies are no longer allowed.