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

indexOf is throwing "Object type does not match RLMResults" exception #2354

Closed
ahayman opened this issue Aug 7, 2015 · 4 comments · Fixed by #2356
Closed

indexOf is throwing "Object type does not match RLMResults" exception #2354

ahayman opened this issue Aug 7, 2015 · 4 comments · Fixed by #2356
Assignees

Comments

@ahayman
Copy link

ahayman commented Aug 7, 2015

I've written a persistence layer around RealmSwift. Everything works fine except I can't seem to use indexOf. When I do, it throws: Object type does not match RLMResults. However, even when I look in the debugger, it shows I'm passing in the correct object type to indexOf. Further details:

In order to "wrap" Realm, I had to create a translation layer to translate between the Realm objects and the "Model" objects I use in the rest of the app.

Example:

public protocol Translator {
  func translate(from: Object) -> Model
  func translate(from: Model) -> Object
}

I created a wrapper around Results, I called Dataset. The Dataset uses a Translator to translate between the objects returned by Results and the Model objects the rest of the app uses.

Because of the limitations of Swift, I could not directly wrap Results<T> (Swift generic types are invariant). So instead, I extended Results with a protocol to provide the functions I needed.

protocol RealmResults {
  func objectAt<T: Object>(index: Int) -> T
  var objectCount: Int { get }
  func indexOfObject<T: Object>(object: T) -> Int?
  func filterOn(predicate: NSPredicate) -> RealmResults
  func sortOn(sorts: [SortDescriptor]) -> RealmResults
}

extension Results : RealmResults {
  func objectAt<T : Object>(index: Int) -> T {
    return self[index] as! T
  }

  var objectCount: Int {
    return count
  }

  func indexOfObject<U : Object>(object: U) -> Int? {
    if let realmObject = object as? T {
      return indexOf(realmObject)
    }
    return nil
  }

  func filterOn(predicate: NSPredicate) -> RealmResults {
    return filter(predicate)
  }

  func sortOn(sorts: [SortDescriptor]) -> RealmResults {
    return sorted(sorts)
  }
}

So Dataset wraps RealmResults and accesses Results<T> using the protocol. This all works fine, except for indexOfObject. It throws Object type does not match RLMResults even though I'm passing in the exact object that Results is expecting.
screen shot 2015-08-07 at 1 08 34 pm

You can see from the debugger that Results is: Results<MessageObject> and the type I'm passing in is MessageObject. Any idea why this may be happening? Is it an issue or am I missing something?

@segiddins segiddins self-assigned this Aug 7, 2015
@segiddins
Copy link
Contributor

Just a guess, but is the object you're passing in not persisted? If that's indeed the issue, I'm preparing a patch right now both to (a) allow that and (b) give a more informative error when the classes actually don't match.

@ahayman
Copy link
Author

ahayman commented Aug 7, 2015

Yes, actually, the object I'm passing in is not persisted, and I'm trying to match it against an object that may be persisted. Is that the issue? The "translator" simply takes a Model object and creates a new "Realm" object from it. Chances are, it's going to exactly match what is persisted, but the actual object itself isn't persisted. It's only created for comparison purposes.

@segiddins
Copy link
Contributor

@ahayman ok, cool! This will be fixed by #2356, since checking for the index of an unpersisted object should just return nil.

@ahayman
Copy link
Author

ahayman commented Aug 7, 2015

Great! Thanks! In the meantime, I can easily work around it by using indexOf(NSPredicate)

@segiddins segiddins removed the pr label Aug 7, 2015
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 17, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants