Get Thing function

[mguerrasio]

Why is there no ‘Get a thing’ capability? In every programming paradigm I am familiar with you are able to load/get/select a record/object/etc. and then use the data from it in your procedure. For example, using a database record as the model, the following is easily done in other tools.

Get specific ‘import’ database record - (ChildFirstName, ChildLastName, DOB, ParentFirstName, ParentLastName)

call the createChild() function like so createChild(import.ChildFirstName, import.ChildLastName, import.DOB)
call the createParent() function like so createParent(import.ParentFirstName, import.ParentLastName)

In Bubble, I must do this

Create a New Thing (child) and then for each field in the child thing I must do:

ChildFirstName = Search for imports:first item’s ChildFirstName
ChildLastName = Search for imports:first item’s ChildLastName
DOB = Search for imports:first item’s DOB

Create a New Thing (parent) and then for each field in the parent thing I must do:

ParentFirstName = Search for imports:first item’s ParentFirstName
ParentLastName = Search for imports:first item’s ParentLastName

So, I have to do 6 lookups compared to 1.

On the other hand, if there was a Get Data function, I could do this:

Get Thing (import) Search for imports:first item

Create a New Thing (child) and then for each field in the child thing I could do:
ChildFirstName = Result of Step 1 (Get a thing)'s ChildFirstName
ChildLastName = Result of Step 1 (Get a thing)'s ChildLastName
DOB = Result of Step 1 (Get a thing)'s DOB

Create a New Thing (parent)
ParentFirstName = Result of Step 1 (Get a thing)'s ParentFirstName
ParentLastName = Result of Step 1 (Get a thing)'s ParentLastName

This is 1 lookup, just like I would do in other tools. Wouldn’t this be far more efficient?

I know that I can accomplish this same thing if I was basing it on a visual component in a page and loading the thing there, but that is not possible in API workflows with no interface component. The work around I have is I create TWO API workflows. The first one is called something like ‘getImportRecord’ and it simply schedules the real workflow I want to run and does the search to pass the thing to the second API workflow. So, I have avoided the unnecessary extra lookups, but at the cost of complexity.

It would be a lot easier if there was a Get Thing function.

Is this something that has ever been asked for?
Does anyone else feel like this would be useful?

Thanks,

Marc

[louisadekoya]

I was getting ready to say, sure you can do this in Bubble but I read your post again and tried to do what you’re after in Bubble. I think I see what you mean. When creating an API Workflow, you cannot start with a search of an item and then reference that search result in subsequent steps.

I think there is (another) possible hack though, which is to make a fake change to a thing. So, use the make changes to a thing action and in that step search for your thing (Child record) and maybe increment a dummy number by one or something. Then your next step can be a create record, using the result of step 1. Not ideal but could work.

I agree however that it would be handy to have a dedicated action to retrieve a thing.

[andrewgassen]

I about wrote the exact same post. It seems like it’s possible everywhere except the API workflow, weird.

[mguerrasio]

Actually, it isn’t even possible in the regular workflow, but because you can access visible elements in regular workflows, there is an easy workaround in just associating the thing with an element (visible or not).

[romanmg]

For regular workflows, I usually set a custom state to the value of the Thing I want to reference. But I do agree that something specifically for this in API Workflows would be great.

[mguerrasio]

I did not even think about the idea of pretending to edit a thing. I did a quick test of that and it does work, so it could be a good workaround, however, since it does work, there is even less of a reason to not have a Get Thing function that was read only.

[NigelG]

@louisadekoya

When creating an API Workflow, you cannot start with a search of an item and then reference that search result in subsequent steps.

You can do the search in the action that calls the API, then pass that.

Surely it does the same thing ? Or am I missing something ?

For API workflows, I tend to try to provide everything that is needed in advance.

[mguerrasio]

Yes, and that is how my extra API Workflow “getThingIWant” works. But what I really do is this.

Schedule API for list (getThingIWant) pass in list
getThingIWant just does a single call to schedule API Workflow “doActualWork” after search to find the thing I want based on the lookup info I passed in from the list

I would prefer to skip the extra workflow and just be able to put a getThing call at the start of the “doActualWork” call.

Make sense?

[NigelG]

I am clearly not getting this

You pass the list of actual things into the “schedule API Workflow on a list”.

Then you have all the data available from the thing, you don’t have to and search for it ?

[mguerrasio]

That is because my example was simplified just to make the request. My real use case is more complicated but I will attempt to make it as simple as I can while still explaining the need.

I have to import data in a format over which I have little control. Customers have legacy systems that output .csv data in a specific way, completely de-normalized. So I get something that looks like this (my real data has a lot more fields):

email	parentFirstName	parentLastname	childFirstName	childLastName	productID
sam@email.com	Sam	Smith	Lena	Smith	AD123
sam@email.com	Sam	Smith	Lena	Smith	BH123
sam@email.com	Sam	Smith	Mike	Smith	KJ123
sam@email.com	Sam	Smith	Mike	Smith	KJ323
karen@email.com	Karen	Jones	Lisa	Jones	AD456
karen@email.com	Karen	Jones	Lisa	Jones	BH456
karen@email.com	Karen	Jones	Tim	Jones	KJ678
karen@email.com	Karen	Jones	Tim	Jones	KJ987

I import a file like this into an import table and then have to build the following things out of it.

1 Parent thing for each unique email address.
1 student thing for each unique child PER parent
1 order thing for each unqiue child per parent
X orderItem things for each unique order thing

This is not something that Bubble is efficient at. For one thing, there is not way to say “grab me the first record of each GROUP of records that share an email address”. So what I do instead if I created a new thing called ‘import_parent’ that has a field for importID which is a unique indetifier I create to make sure the records from one import are separate from records for another one that happens at or near the same time. It also has a field called emails that is a list of text items. I fill that email list field like so: emails add list Result of Upload Data as CSV’s email:unique elements

I then pass the emails list to a ‘Schedule API Workflow on a list’ for my ‘getThingIWant’ API worflow. In the exmaple, that would fire off 2 API workflows. That ‘getThingIWant’ workflow does one thing, it calls ‘Schedule API workflow’ for my ‘doActualWork’ workflow passing an IMPORT thing that is the result of a search of the import table for the FIRST record that matches the email address. And from there, away we go. I then have to do it again for creating children things etc.

If there was a ‘Get Thing’ function I could avoid the extra API workflow. If there was a way say “grab me the first record of each GROUP of records that share an email address” I could also avoid the extra workflow.

Obvisouly, it is possible I am completely missing an easier way to do this, and if anyone knows it, I’d love to hear it, but after dorking around for a day on this, I created this method and it works fine.

Regardless of whether there is a different way to do wat I want, I still think that a ‘Get Thing’ feature makes sense and given that you can basically trick the system by doing an ‘Edit a Thing’ without editing it, it seems like this should be a somewhat trivial addition.

Marc

[laurence]

@NigelG

You can do the search in the action that calls the API, then pass that.

Surely it does the same thing ? Or am I missing something ?

For API workflows, I tend to try to provide everything that is needed in advance.

The drawback here is that you probably are not appropriately encapsulating the logic of the API workflow. The triggering workflow probably shouldn’t have to know about the thing needed by the API workflow to complete its task.

@NigelG

For API workflows, I tend to try to provide everything that is needed in advance.

I would posit that getting stuff to pass into a workflow that is really only needed inside the workflow is a concession to something lacking in the design of programming architecture. The requirement to pass something into a workflow that is only needed (and should only be understood) by the workflow violates the concept of encapsulating functionality that has been around since the '70’s and has held up well in object oriented programming.

[laurence]

What I see is that API workflows don’t support custom states at all. Am I missing something?