Creating an object with properties that are new objects which consist of the exact same properties as other new objects causes schema error

[jaysonng]

New Issue Checklist

• I am not disclosing a vulnerability.
• I have searched through existing issues.
• I can reproduce the issue with the latest versions of Parse Server and the Parse Swift SDK.

Issue Description

saving an object with pointers and pointers point to objects with the same struct causes schema error when saving.

caught error: "ParseError code=111 error=schema mismatch for TestObject.test1; expected Pointer<Test1> but got Pointer<Test3>"

Parse-Swift in the middle of saving the pointers gets confused as to what the object is.

Steps to reproduce

Given something like so:

    struct Test1: ParseObject {
        //: Those are required for Object
        var originalData: Data?
        var objectId: String?
        var createdAt: Date?
        var updatedAt: Date?
        var ACL: ParseACL?

        var description: String?
    }
    
    struct Test2: ParseObject {
        //: Those are required for Object
        var originalData: Data?
        var objectId: String?
        var createdAt: Date?
        var updatedAt: Date?
        var ACL: ParseACL?

        var name: String?
    }
    
    struct Test3: ParseObject {
        //: Those are required for Object
        var originalData: Data?
        var objectId: String?
        var createdAt: Date?
        var updatedAt: Date?
        var ACL: ParseACL?

        var type: String?
    }

    struct TestObject: ParseObject {
        //: Those are required for Object
        var originalData: Data?
        var objectId: String?
        var createdAt: Date?
        var updatedAt: Date?
        var ACL: ParseACL?

        var test1: Test1?
        var test2: Test2?
        var test3: Test3?
    }

    func testSaving() async throws {
        var acl = ParseACL()
        acl.publicRead = true
        acl.publicWrite = false

        var testObject = TestObject()
        testObject.test1 = Test1(ACL: acl)
        testObject.test2 = Test2(ACL: acl)
        testObject.test3 = Test3(ACL: acl)

        do {
            try await testObject.save()
        } catch {
            throw error
        }
    }

running testSaving() will cause the schema error.

Even if there's only 2 that are the same - will cause an error.

        var testObject = TestObject()
        testObject.test1 = Test1(ACL: acl, description: "test1")
        testObject.test2 = Test2(ACL: acl)
        testObject.test3 = Test3(ACL: acl)

However, adding extra arguments to differentiate each object clearly like so:

 func testSaving() async throws {
        var acl = ParseACL()
        acl.publicRead = true
        acl.publicWrite = false

        var testObject = TestObject()
        testObject.test1 = Test1(ACL: acl, description: "test1")
        testObject.test2 = Test2(ACL: acl, name: "test2")
        testObject.test3 = Test3(ACL: acl, type: "test3")

        do {
            try await testObject.save()
        } catch {
            throw error
        }
    }

will save the testObject successfully.

Actual Outcome

schema error

caught error: "ParseError code=111 error=schema mismatch for TestObject.test1; expected Pointer<Test1> but got Pointer<Test3>"

Expected Outcome

object should still save successfully.

Environment

Client

• Parse Swift SDK version: 5.8.3
• Xcode version: 15.2
• Operating system (iOS, macOS, watchOS, etc.): MacOS
• Operating system version: 17.1.1

Server

• Parse Server version: 6.4
• Operating system: MacOS
• Local or remote host (AWS, Azure, Google Cloud, Heroku, Digital Ocean, etc): local

Database

• System (MongoDB or Postgres): mongodb
• Database version: 6
• Local or remote host (MongoDB Atlas, mLab, AWS, Azure, Google Cloud, etc): local

Logs

[jaysonng]

To be honest I'm not sure if it's a Parse-Swift problem or something deeper with Swift itself.

But I figure the way it acts that it's something with how Pointer interacts with saving.

[cbaker6]

If you run into situations like this, you should save the objects Test1, Test2, and Test3 separately and first before adding them to TestObject. I imagine the problem is the items are currently unsaved and look exactly the same when they are encoded, so the SDK is having trouble differentiating them. As soon as they are saved and obtain an objectId, the SDK can differentiate them. You also shouldn’t run into this problem if you are using custom objectIds

[jaysonng]

Ah i see. Gotcha.

So this isn't a bug or something we can add as. Feature request?

Thanks!

[cbaker6]

I’m not sure if it will get addressed as saving like this is something that shouldn’t occur and is more of a developer error. If Test1, 2, or 3, are going to have zero properties set initially, just leave them as nil on TestObject, update the respective properties when you really have something to save. Or, if you are going to create multiple ParseObjects that have the same properties/fields, just represent them as 1 ParseObject and take advantage of “querying”.

In your examples it seems you are trying to set ACL’s. You can do that with CLP’s or by using Cloud Code when those objects are created.

[jaysonng]

I’m not sure if it will get addressed as saving like this is something that shouldn’t occur and is more of a developer error. If Test1, 2, or 3, are going to have zero properties set initially, just leave them as nil on TestObject, update the respective properties when you really have something to save. Or, if you are going to create multiple ParseObjects that have the same properties/fields, just represent them as 1 ParseObject and take advantage of “querying”.

In your examples it seems you are trying to set ACL’s. You can do that with CLP’s or by using Cloud Code when those objects are created.

I initially encountered this problem when I ran a check on login to make sure my User object has all the Pointers it needed. if not, it creates those objects and adds it in. They're all blank objects to start with but those objects of course can be edited by the user once they login.

so I needed them "blank".

All good though. Saving before hand worked well.