Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Realm Object isEqual(_:) override #7781

Closed
igorvoytovich opened this issue May 3, 2022 · 5 comments
Closed

Realm Object isEqual(_:) override #7781

igorvoytovich opened this issue May 3, 2022 · 5 comments

Comments

@igorvoytovich
Copy link

igorvoytovich commented May 3, 2022

Hello,

Could you please tell if it is safe to override:

{{func isEqual(_ object: Any?) -> Bool { ... }}}

for Realm Objects?

I heard that Realm objects with primaryKey override it by default, but we use detached objects in several cases and need to be able to compare them too.

For example, if we have:

class Item: Object {
    @Persisted var id: String
    @Persisted var field: String

    override class func primaryKey() -> String? {
          return "id"
    }
}

If we add:

func isEqual(_ object: Any?) -> Bool {
    guard let c = object as? Item else { return false }
    return id == c.id
}

to this class,

Can something break or go wrong? Could this lead to some unexpected behavior in production or is it completely safe?

Thanks.

P.S.
Or maybe you can tell how to correctly implement objects comparison so that it works for detached objects as well? Maybe something related to Hashable and hashValue would be more correct?

@dianaafanador3
Copy link
Collaborator

Hi @igorvoytovich you should be able to compare between two detached (frozen) objects without overriding the isEqual function. How are you deataching your objects?, Can you give a little bit more context so I can help you.

@sync-by-unito sync-by-unito bot added the Waiting-For-Reporter Waiting for more information from the reporter before we can proceed label May 3, 2022
@igorvoytovich
Copy link
Author

igorvoytovich commented May 3, 2022

Hi @igorvoytovich you should be able to compare between two detached (frozen) objects without overriding the isEqual function. How are you deataching your objects?, Can you give a little bit more context so I can help you.

Hi @dianaafanador3,

Thank you for your response.

We use this code: #5433 (comment)

We can not use Realm's frozen objects due to their implementation nuances. (realm/realm-core#5043 (comment))

@github-actions github-actions bot added Needs-Attention Reporter has responded. Review comment. and removed Waiting-For-Reporter Waiting for more information from the reporter before we can proceed labels May 3, 2022
@dianaafanador3
Copy link
Collaborator

ok I understand. Regarding overriding isEqual for that particularly Object Type there is no issue, as we don't use this internally, and you will be overriding it for just this Object Type. Have in mind that for comparing managed objects you will have to use public func isSameObject(as object: Object?) -> Bool if you want deep comparison.

@igorvoytovich
Copy link
Author

Thanks @dianaafanador3 ,

This is exactly what we wanted to know. There were fears that this function can be used somewhere inside the Realm internal logic, for example, when updating objects with a primary key, in order to check for the presence of an object in database or something like that. Now it's all clear.

Thanks again! We can close this case now.
Have a nice day!

@sync-by-unito sync-by-unito bot removed the Needs-Attention Reporter has responded. Review comment. label May 3, 2022
@xingheng
Copy link

ok I understand. Regarding overriding isEqual for that particularly Object Type there is no issue, as we don't use this internally, and you will be overriding it for just this Object Type. Have in mind that for comparing managed objects you will have to use public func isSameObject(as object: Object?) -> Bool if you want deep comparison.

So can we just override that isSameObject function to add additional compare logic?

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 18, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants