If these 10 objects you insert with bulkInsert need to be related with 10 different users, it would mean you would need to subsequently update each individual user separately.
To answer your question, I need to understand your data model better. For example:
Where did you define the relationship column? In the Users table or the other table (not sure what the name of it is)
Is the relationship define 1:1 for a reason? If so, what is it?
What is the actual use case whe you need to insert multiple objects (at once) and establish relationship between these insert objects and a collection of other (presumably parent) objects?
I insert the 10 rows into Contac using the Bulk Upsert (the values could exist) the collection of objectIds is returned for the rows I just upserted. Those rows are the parent objects, I need to add the relation to the User table for all of them. Do I use that returned collection as the parent object in the Add Object Relations Data API logic?
These two points seem to contradict each other. If a User owns Contacts, the relationship column should be defined in the Users table and it should be a 1:N relationship. A relationship columns typically reflects the “has a” or “owns” type of relationship between the entities.
If you declared the relationship column in the Contacts table and that column points to Users, then your contact “owns” the user. While it still could work, I believe it incorrect as the reverse relation definition (one created in Users) would make more sense.
With that being said, when you create N objects with Bulk Create, the block returns a collection of created objectIds. These are child objects. Then you establish a relationship for the current user object (which is the parent) by passing a collection of created objectIds as children.
I was also just wondering about the his question about the difference between ADD relation and SET relation - Please correct me if I´m wrong in my understanding:
1.) when you use ADD relation you are adding to a list of 1:N relations (correct? Or can it be used for a 1:1 relation too?)
2.) when you SET are you simply telling Backendless to replace whatever relation (or list of relations) exist currently with the new relation (or list of relations)?
Almost correct, there can be to cases for 1:1 and add relation method:
a. The related object does not exist. In this case, a relation will be established.
b. The related object already exists. In this case you will get an exception:
Unable to update relation. Another child object is already present in OneToOne relation and cannot be replaced with addRelation. Use the setRelation API instead.
We have a collection of objects (call them “connected objects”) in a table which all have a 1:1 relation to “object A” in another table. Sometimes, we need to delete “objectA” and create “object B” in that other table… but we need “connected objects” to be updated so they point to “object B”.
Basically, we need to bulk update a collection of objects whose relation points to “object A” such that their relation will point to “object B”. Is there a simple bulk operation we can use? Or do we have to create a loop and set a new relation on each individual object in the list of “connected objects”?
That is a pity, especially when API counts are becoming the key driver behind billing.
I am sure all customers would appreciate if you could look into providing such bulk methods, because in the end it would be win-win : for Backendless, and for customers. Less server calls and load, and easier logic building. Especially for features which could be performed in SQL with a single line : UPDATE table XYZ SET key = 'abc' WHERE key = 'def';
I’ve created a ticket to discuss this feature.
We will update you on the discussion outcomes in this thread.
Thank you for your excellent ideas, you’re helping make Backendless even better.
I would like to know if Bulk Add/Set/Remove Relations will be coming at some point. It is quite a subject for API optimization + ease of use. And as discussed above, it is relatively standard in databases.
Not to beat a dead horse to death… but it seems lots of people need to do bulk relation operations… so I’m just re-iterating a “request for bulk relation updates” here
We are about to create cumbersome loops with transactions that contain batched operations, seems a pity to have to create such code. Our particular situation: we have a collection of objects and need to add a new relation (add a new child in a 1:N relations column) to each of them. I imagine this is a very common pattern, for example when you want to add a “tag” to a collection of objects. By chance is something like “bulk add relation” on the roadmap for Backendless Codeless blocks?
The set relation API currently accepts one parent object and a collection of children. What you’re asking for is support for updating a collection of parent objects with a child (or perhaps multiple children). Is that correct?
The essence of the issue here is that all Backendless APIs that work with the database transform into a single database query. What you’re asking (if I understood correctly) is not possible with a single query, so it would have to be implemented as a routine that issues multiple queries (which goes against the main principle we follow).
It can be implemented relatively easy with a reusable function that takes a collection of the parent objects, loops through it, and calls the Set Relation API for each. This “cost” of that operation in terms of the number of API calls would equal the size of the parent collection.
Hi Mark, also chiming in, because I am very surprised by what you are stating.
As said above, the needed operation could be performed in a single call in a standard SQL database. Is there not a way for you to arrange it so that it is a single API call, and then a batch update behind that ?
Relationships are set in a different way than regular column properties. As a result, a single query to update relationships for multiple primordial objects is not possible.
