Hi All,
with having ‘make a change to a list of things’ and delete a list of things, there must be a clear reason why we cannot ‘Create a new list of things’. I really could use it though.
Userstories are, you want to create a thing for a certain set of users for instance.
Could you guys use this as well? Or do you have workarounds?
We do have something for this:
Also, do take a look:
http://forum.bubble.io/search?q=schedule%20list%20api%20workflow
Thanks for responding! That does look like a pretty elaborate workaround, whereas at the same time the bubble team has done a great job making a simple and very accessible ‘make change to a list of things’ command?
Yeah, that command is for smaller, more instantly needed list operations and is quite heavy. It only works on up to 100 things. If your user won’t need the list operation’s result “right now”, then scheduling workflow is the best way to go.
Even if some result is needed right now, you can use custom states, filters and other client side functions to display something while your app is working on the list in the background.
Hey @SenorPelota, (also @vini_brito): I had thought that @vini_brito’s link would lead to the documentation for the bulk create feature of the data API. Instead, he links to “schedule API workflow on a list”. I’m not sure why he does that as it doesn’t really answer your question.
Sure, if you can construct a list of “n” length, you can fire off an API Workflow on a List and, inside of that workflow, Create a New Thing of some custom type. (The arbitrary list of length n acts as a “for each” sort of loop.) And, ultimately, you will have created n new things.
While we have a bulk create (note its limitations) feature in the data API and can multiply create items in the way I describe above, this still seems rather strange. (And, you will also note that not only is there no “Create Multiple New Things / Create a List of New Things” sort of action, there are also no “Create List of Primitive Data Type” workflow operations.)
Before I go on to muse about why this might be. Let me provide a couple of “workarounds” for creation of multiple new things:
So lets say you have a Thing called Car in your database and you wanted to instantiate 10 new Cars in a single workflow, you could “Copy a List of Things” where the source is Do a Search for… Cars (with NO constraints and NO SORTING):items until #10. This will just grab the first 10 Car objects that can be found, copy them, and return them in a list.
You could then as a next step use “Make Changes to a List of Things” (source: the list returned by Step 1) to set their fields to some default values or whatnot. (If you need to change each individually, you might use Schedule API Workflow on a List to make whatever changes are needed.)
As noted before, you could ping your own bulk create API (see the Reference link noted earlier – this is on the GET/data side of the API). You can in fact do this in the API Connector (call your app’s own API endpoints) and I show an example and talk about this strange idea (which totally works, BTW) in my video about the Amazon Product API (search @keith Amazon product API should turn that up for you).
You could iterate over an on-page workflow using Toolbox’s JavaScript to Bubble element and a Run JavaScript action. (I did once post more-or-less exactly how this is done, but I’m kinda loathe to explain it again.)
I feel like #1 is your best bet and note that you could manually create a “template” list of things that you want to bulk create in your database and attach them to some other object and just retrieve THAT list as the Copy source.
SO, BACK TO THE ISSUE of why it might be that this is so hard.
Note that, even beyond the fact that “Create New Thing (List)” is missing (such a feature would allow us to create n new things of a given type), you can’t even create an arbitrary list of primitives (make a list of numbers 1 thru 10, for example, or make a list of 7 texts) via a workflow action.
As Bubble has all the makings of a true “array-oriented language” (and I’ve always seen it this way), the fact that there’s no facility for creating such arbitrary lists seems like a very strange oversight.
I think the REASON Bubble lacks these facilities goes back to the earlier versions of Bubble where iteration was very, very, very frowned upon. And it could be that such functions (especially creating lots of new Things all at once, which is very database intensive) may have been seen as potentially dangerous to shared server stability.
Over time, Bubble has relaxed restrictions against iteration on the server (for example Schedule API Workflow is a form of iteration, recursive API workflows are a form of this, and most recently we have gained access to the server-side actions API, which enables the creation of arbitrary lists of primitive data types – though it does not let us perform Create or Make Changes operations on the database).
Some of the server side actions that I’ve been working on do just this type of thing. (Give me a list of numbers, give me a list of dates, generate a list of texts (like uuids), etc.) … And this makes Bubble a bit more like an array-oriented language as one now has things that one can usefully iterate over without looping.
The downside at present is that such operations are pretty slow. Part of this may be due to bugs/optimizations that Bubble is still working on for SSAs. But part of it is simply due to Bubble’s conservative allocation of CPU time. At the moment, I’m not sure how fast such simple actions might ever be. Returning a list of 10 created primitives is quick-ish. A hundred slightly less so. And then, each order of magnitude beyond that puts you very much in non-real-time territory.
Just some observations on this issue! Super good question, @SenorPelota!
One of my use cases for needing the ability to create multiple ‘things’ is for unique (promo) codes. I’ve managed to hack together a method using Schedule API Workflow with an arbitrary list. I think I’ve got it worked out well enough that I shouldn’t have any problems, but it would still be much nicer to have a baked in solution; something w/o so many moving parts.
Actually, I just came to a roadblock… I’m realizing that I can only create as many new ‘things’ as the number of items I have in the DB to create a list from. In other words, I have to create an arbitrary list of something in order to run an API workflow (to actually create the things) and if the most things that I have is 5, then I can’t create 6 things… hmmm…
(Whew… if that’s not confusing to understand, I don’t know what is.)
That’s not true at all. You can have an API workflow endpoint with only two steps that will create new things until a certain condition is met.
Here’s your API workflow called Ever Running
Workflow step 1: Create a new thing - Whatever you want to create.
Workflow step 2: Schedule API workflow Ever Running (itself).
This would make it create new things endlessly forever, never stopping, breaking your whole app in a few days, maybe in less time.
You then must have a condition to be checked on step two, and it would depend on your app’s logic.
You can have far more steps before the workflow reschedules itself (if needed), but make sure you do it right by properly restraining the “schedule itself” action.
That makes perfect sense. I wonder why I didn’t do that before… hmm…
@keith The whole API looping solution does work, and with a bit of tweaking it now seems to work so my workflows won’t time-out because of time limits. Super good insight. I do sympathize with the original thought process of not wanting to stimulate users into doing the things which will put the (then) Bubble startup into a performance black hole.
But now that we can work around it, isn’t it just time to make the direct shortcut?
I mean, we all receive the warnings changing a list or deleting it ( or moving it) past n+whatever will bring us in performance hell. Might just as well extend that warning and fix the pothole in the road? @neerja?
Can we use “Copy list of things” to copy data from one table to another ?
Can anyone assist me on this please ?
Hi, yes, it can be done, on lists up to 100 items.
Here’s what the manual says about that action:
This action duplicates a list of things.
Important: For performance and security reasons, the number of things in the initial list is limited to 100 entries. If the length of the list exceeds this, the action will do nothing.
Select the type of thing to copy. This is needed to test the type consistency with the list.
Define the list to copy. It can either be the result of a search or the content of a field that is a list of things. If the type is inconsistent, the expression will be red, and the action will not complete.
Thanks @vini_brito
But as you mentioned, In manual it says “This action duplicates a list of things” . Did that mean the records can only copy into the same table. (making duplicates of list of things into same table) ?
If it can copy the list of things of one table to another (Ofcourse, with limit of 100 records), where can I give the destination table ?
Here I can only see the source.
By another table you mean a different data type? I missed that, sorry.
To do that you can use a scheduled API workflow. Have you looked into that? It’s only accessible in a personal or above plan though.
