Backendless 4.0: Set Relation does not override previous value

iOS
1

I have a 1:1 relation set up in table A.

Calling the .setRelation function with the following signatures does not override the old relation, rather appends it (like you would expect with the addRelation function).

Backendless.Persistence.of(TABLE_CLASS).setRelation(parentObject, "columnName:TableName:1", Arrays.asList(relationObject));

Backendless.Persistence.of(TABLE_CLASS).setRelation(parentObject, "columnName", Arrays.asList(relationObject));

I tried both signatures - one with the cardinality syntax and without. No matter where I call this .setRelation function, the same behaviour is observed (tested this in a server code function, as well as on iOS).

The odd part is that this should not be possible at all, especially when the schema is explicitly set to a 1:1 and not a 1:N. The backendless console even displays that somehow, two objects are set (in this case), regardless of it being a 1:1. Clicking on the relation will still filter down and display the N records that are “set” in the other table.

http://support.backendless.com/public/attachments/68fd91f84148fd155dc8ddffb72030bd.png</img>

On a related note, I am trying to set a relation to the User table (also 1:1), and the operation fails because the objectId of the user is seen as null (also observed this in both server code and via iOS SDK).
Error Returned:

FAULT = '1303' [Unable to create relation. Child object with id 'null' is not found in the related table.] <Unable to create relation. Child object with id 'null' is not found in the related table.>

I have verified that the user’s objectId is in fact not null, before passing it off to the set relation function in iOS or the cloud code function. This issue seems to just be with the Users table - I don’t get the null error with the other relations that I try to set.

Any help is greatly appreciated!
Thanks,
Renato

68fd91f84148fd155dc8ddffb72030bd.png

2

Hi Renato,

We will verify this and report back. Do you use Java or JS in the cloud code function?

Mark

3

Thanks, Mark.
For cloud code, I’m using Java. I can share the cloud code project again if that would help?

4

Hi Renato,

thank you for reporting your issue, our developer is already looking at this problem and will soon let you know about the results. The internal ticket ID is BKNDLSS-14799.

Regards,
Stanislaw

5

Thank you guys, I see that the 1:1 relation issue is fixed in v4.0b15 released today.

However, I am sill observing the issue with setting the relation to a user, with its id “not found in the related table” - seems like someone else is also seeing this issue. I also just grabbed the latest backendless.jar from the android sdk on github and it still produces the same result when the service is run.

Would you be able to update when that gets resolved?

Thanks again for the support!
Renato

6

Hi Mark & Stanislaw,

I have some more context regarding these issues. I’m not sure what happened, but the first issue has partly resurfaced, or wasn’t completely resolved.

Calling the .setRelation function in Java BL still results in the old relation not being overwritten (both in debug & prod):
http://support.backendless.com/public/attachments/78c7bc42f71a0841ba25278963e76698.png</img>

However, if I call the .setRelation function directly in iOS (bypassing BL), it is works fine and replaces the previous relation.

For the BL, I made sure to grab the latest backendless.jar that was released earlier today from the github repo, thinking it would also resolve my second issue with setting the 1:1 relation to the user table (seeing as how the issue in a similar thread was resolved). With the new jar, I then updated & cleaned the project, rebuilt & deployed the service after also removing it from backendless first).

Setting the relation to the users table in my BL function (PROD) still results in the "Child object with id ‘null’ is not found … " error, but setting this user relation direct with the iOS SDK works as expected. The even odder part is when I run the same BL function in debug, it successfully sets the 1:1 relation to the user table.

Renato

78c7bc42f71a0841ba25278963e76698.png

7

Hello Renato,
The internal ticket BKNDLSS-14799 is in progress. We’ll inform you as soon as this issue will be fixed.

Regards, Olga

8

Hi Mark / Olga, I was just wondering if there was any update to this?

Thanks,
Renato

9

Hi Renato,

I will check it now. To make sure I am doing the same thing: is the problem confined to Java BL or the client-side as well?

Regards,
Mark

10

Thanks, Mark.

I just checked this morning, and calling the .setRelation with the iOS SDK seems to be working as expected.

When I try to do the same with the Java SDK, it seems to still be broken, so I think you are correct in saying it is confined to Java BL.

11

Hi Mark, was there any update to this?

12

Hi Renato,

I couldn’t reproduce it with the following code on a new app:

Backendless.initApp( "63E720B3-398F-B125-FFC8-A64A9F24B300", "D3289D8D-4AF2-7E50-FF31-F060F91B7800" );


//    final Person person = Backendless.Data.of( Person.class ).findById( "9D6C0CF1-CF89-5E02-FFC0-1DBE16C68B00" );
final Person person = Backendless.Data.of( Person.class ).findById( "5659008E-271A-5A1B-FFB7-A831B3660100" );
final Parent parent = Backendless.Data.of( Parent.class ).findById( "EA52484C-8BF9-07C0-FF0C-DDC96DFF0F00" );


final int relations = Backendless.Data.of( Parent.class ).setRelation( parent, "person", Collections.singletonList( person ) );-

I created a table Parent with 1 entry, a table Person with two entries, and a relation between them; called setRelation for the first one, then called setRelation for the second one. This resulted in only one related object - the second one. Could you please verify it, too?

13

I’m just a little puzzled as to how this went from being a known issue and a developer “already looking at this problem”, to now not being reproducible?

I just triple checked everything … made sure my jar was the latest from the java/android project in github, recompiled, pushed to prod, and ran the service again, with the issue still persisting - console showing two relations set, and the other relation broken because the objectId is apparently null.

Testing against a brand new app seems a little one-sided, especially since this is starting to sound like an environmental / app related issue. Would you consider trying to replicate it on your end if I upload my cloud code project like I have had to do with previous issues? I also wouldn’t mind demo-ing exactly how this seems to be broken if you would entertain something like a skype / go-to-meeting (Maybe I’m missing something, despite following the documentation)?

I’m just a little reluctant to moving everything over to a new app, testing there, and accepting that as the solution if it works, when i’ve already had to do that with a previous issue (see here: http://support.backendless.com/t/backendless-4-0-cloud-delete-request-returns-14002-service-method-not-found)

One other question - is it required to do a query on the server side in order to retrieve the object? Can I not just use the object that was passed into the call of my Java cloud code function when setting the relations? - Could that somehow be what’s causing the issue?

Renato

14

Renato,

As the service is in beta, it is likely that apps created at different stages could manifest different behavior. In fact (heads-up), before 4.0 goes out of beta, all business logic must be redeployed because of some critical changes introduced in the last phase.

We do not mind taking a look at the code, however, it the same code works in a new app, it would give us the guarantee that the functionality works.

I hope you understand our approach and the line of thinking.

As for your question, I do not believe you do not need to retrieve the object if you already received from the client inside of your handler. The SDK code uses the object to obtain its objectId:
https://github.com/Backendless/Android-SDK/blob/4_0/src/com/backendless/DataStoreFactory.java#L398

Regards,
Mark

15

Hi Mark,

Thanks for the heads up … I certainly do not mind re-deploying BL, it is just less than ideal to have to copy over an entire app, especially when there is currently no (scripted) way to export all of the data/config (like the constraints / validators I have in each table).

I setup a very simple debug app to try and mock the scenario I am running into, and after some testing, it seems that a clean slate behaves as expected - no null object id when setting the relation to the user and no multiple relations on a 1:1.

Since you don’t mind taking a look at the code, I will send the project over to the support email.

Appreciate it!
Renato

16

Hi Renato,

There was a problem with your app’s database, which I fixed manually. So now you shouldn’t be able to create more than 1 relations in 1-to-1 column.
Can you please tell us how most of your relation columns were created? It would help us investigate the cause of the database problem.

17

Hi Sergey,

Most of the table columns in my application’s schema were created some time ago, way back when I was using backendless 3.x. I wonder if there was something that went wrong when migrating the 3.x app over to the 4.x beta?

Renato

18

Yes, I also think this could be caused by the migration process. We’re going to investigate this question.
As to your app, everything should work fine since now.

19

Thanks!

20

Hi again,

Can you please provide the app ID of your original 3.x app? We would try to test the migration using it, since the problem did not reproduce with any other one.