DB record's relation prop is not received

Data Service
1

Our current backendless version: Pro v7.0.14

Steps to reproduce:

  1. Create DB table City with columns:
    name: string

  2. Create other DB table People with columns:
    name: string,
    city: - DataRelationObject(1:1), RelatedTable: City

  3. Insert a record to City table

  4. Insert a record to People table, add to it a related record in City.

  5. Try to get a record from People, with relations city and the props city

Actual result: the record returns with city: null
Expected result: the record returns with city: CityRecord data here

here is the POST requests I sent:
1) Works GOOD - /data/People?loadRelations=city
returns:

[
    {
        "city": {
            "name": "Berlin",
            "___class": "City",
            "ownerId": null,
            "updated": null,
            "created": 1742384624039,
            "objectId": "8CBA0917-0239-49C5-8095-40D2A69E8CB7"
        },
        "created": 1742384640026,
        "name": "John",
        "___class": "People",
        "ownerId": null,
        "updated": 1742385281279,
        "objectId": "19129738-C00B-4615-948B-D4EBF574AB8D"
    }
]

2) Works WRONG - /data/People?loadRelations=city&props=city
returns:

[
    {
        "___class": "People",
        "city": null,
        "objectId": "8CBA0917-0239-49C5-8095-40D2A69E8CB7"
    }
]

And in request #2 the city props should not be null.
That is how it was working in Backendless v6.

Is it an expected behavior or a bug?

PS: in BL v6, request #2 returns like:

[
    {
        "___class": "People",
        "city": {
            "name": "Berlin",
            "___class": "city",
            "ownerId": null,
            "updated": null,
            "created": 1742384729383,
            "objectId": "BDCF5D1D-6D80-428E-A2BC-0D4F3A121B47"
        },
        "objectId": "38C9DEA7-2856-46E8-A955-6250F4E1EA86"
    }
]

cc: @sergey.kuk

2

more details, here are table created by me

image
image1806×433 45.2 KB

image
image1829×534 50.1 KB

3

Hello @Sasha_Grin,

This isn’t exactly a bug. When using props, you should reference the specific field of the related object rather than the object itself. For example, /data/People?props=city.name will return the names of the related objects in the response.

When using props, Backendless functions similarly to MySQL by performing joins, allowing data retrieval with a single database request. This approach also enables the use of aggregation functions and other optimizations.

However, when using loadRelations, no join is performed. Instead, the parent object is retrieved first, and then additional calls are made for each related object.

We do not recommend using loadRelations and props together. However, if you try /data/People?loadRelations=city&props=city.name, the response will be similar to:

json
[
    {
        "city": {
            "name": "Berlin",
            "___class": "City",
            "ownerId": null,
            "updated": null,
            "created": 1742384624039,
            "objectId": "8CBA0917-0239-49C5-8095-40D2A69E8CB7"
        },
        "name": "Berlin",
        "___class": "People"
    }
]

In BL v6, request #2 returns something like this:

If you’re testing this with an older app, the behavior may differ. In a new app, it should be consistent with version 7, but I could be mistaken.

Regards,
Serhiy

4

the issue is that I already have pretty large codebase and now it was migrated to BL v7, that is pretty hard to find and debug all that issues.

Thank you.

5

@Sasha_Grin could you check please if the new app on BL6 have the same behavior on as on BL7.

6

@sergey.kuk Yes, For this test I created a new App on our existing BL v6(Pro v6.6.7) server as we use for our other apps.

result - it works the same as in the BL v6 Apps, as expected, returns related property:

[
    {
        "___class": "People",
        "city": {
            "name": "London",
            "___class": "City",
            "ownerId": null,
            "updated": null,
            "created": 1742462283284,
            "objectId": "7DEB6AA8-7B3C-4558-AE11-355261AB5167"
        },
        "objectId": "F06847B2-B1DF-4FE9-A8B8-DA57E8CDAFCC"
    }
]

It is pretty important because what if I need a lot of properties of related object(actually the whole object)? should I list them all and update the list if something is changed/added to the Model? :frowning:

Disappointed because some backward compatibility was expected here.

7

@Sasha_Grin

I see your problem, I’ll investigate more and let you know what we can do

8

Hello @Sasha_Grin,

After further investigation, unfortunately, we’re unable to provide a direct solution in this case.

As part of the Data Service’s evolution, we transitioned to more native interaction with MySQL to improve performance. In the current behavior, when you use the query parameter props=city, the system performs a join on the city table and MySQL selects the objectId from the related city object, rather than from the parent table. As a result, it attempts to load the related object using an invalid objectId. I understand this may sound a bit complex, but that’s the root cause of the issue.

Additionally, I’d like to point out that the following request is not correct:
/data/People?loadRelations=city&props=city
The props parameter should refer to a specific property, not an entire object.

As a workaround (for version 7+), you can implement a beforeEvent handler to intercept and either modify or remove the props parameter. This can give you time to adjust your client-side code accordingly.

Let me know if you need help setting up that handler or if you have any other questions.