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

Linking Object attributes don't exist when not in realm #4195

Closed
asjesset opened this issue Oct 7, 2016 · 7 comments · Fixed by #4196
Closed

Linking Object attributes don't exist when not in realm #4195

asjesset opened this issue Oct 7, 2016 · 7 comments · Fixed by #4196
Assignees

Comments

@asjesset
Copy link

asjesset commented Oct 7, 2016

Upgraded to Realm 2.0.1 from 1.X and been having some crashes when adding new objects.

It looks like an object with linking properties crashes if i try to access its linking objects before it's added to realm. I think in 1.X the behavior was to return an empty list.

Did this behavior change? What's expected here:?

@asjesset
Copy link
Author

asjesset commented Oct 7, 2016

I verified the behavior changed from 1.0.2 to 2.0.2.

Accessing an unmanaged RLMObject's linking object properties in 1.0.2 results in an empty RLMResults, but in 2.0.2 you get this exception:

#0  0x0000000103b6e3ad in -[RLMFastEnumerator countByEnumeratingWithState:count:] at /Users/realm/workspace/create_github_release_cocoa/realm-cocoa/Realm/RLMCollection.mm:95
#1  0x0000000103b6eeae in RLMDescriptionWithMaxDepth(NSString*, id<RLMCollection>, unsigned long) at /Users/realm/workspace/create_github_release_cocoa/realm-cocoa/Realm/RLMCollection.mm:190
#2  0x0000000104ad43d9 in _NSDescriptionWithLocaleFunc ()

As a workaround, using "count" appears to still work (returns 0 if not in a realm already). I will be wrapping all my iterators in this unless this is fixed...

@asjesset
Copy link
Author

asjesset commented Oct 7, 2016

The EXC_BAD_ACCESS appears to occurs in RLMCollection.m:95:

- (NSUInteger)countByEnumeratingWithState:(NSFastEnumerationState *)state
                                    count:(NSUInteger)len {
    [_realm verifyThread];
    if (!_tableView.is_attached() && !_collection) {
        @throw RLMException(@"Collection is no longer valid");
    }
    // The fast enumeration buffer size is currently a hardcoded number in the
    // compiler so this can't actually happen, but just in case it changes in
    // the future...
    if (len > RLMEnumerationBufferSize) {
        len = RLMEnumerationBufferSize;
    }

    NSUInteger batchCount = 0, count = state->extra[1];

    Class accessorClass = _info->rlmObjectSchema.accessorClass; //EXC_BAD_ACCESS here

@bdash
Copy link
Contributor

bdash commented Oct 7, 2016

Thanks for the detailed bug report. I was able to reproduce this by adding a new test case in Realm:

PersonObject *don = [[PersonObject alloc] initWithValue:@[ @"Don", @60 ]];
XCTAssertEqualObjects(asArray(don.parents), (@[ ]));
for (PersonObject *parent in don.parents) {
    (void)parent;
    XCTFail();
}

@markst
Copy link

markst commented Mar 29, 2017

Hey I still appear to be having this issue. Using version 2.4.4.

class User: Object, Resource {
    
    dynamic var id: String? = nil
    dynamic var email: String? = nil
    dynamic var firstName: String? = nil
    dynamic var lastName: String? = nil
    dynamic var phone: String? = nil
    dynamic var company: String? = nil
    
    var organisations = List<Organisation>()
    
    let sessions = LinkingObjects(fromType: Session.self, property: "user")

My linking objects is empty outputting my sessions to output log:

override var description: String {
    print("self.sessions: \(self.sessions)")

Until I add all the 'sessions' which should fulfil the linkage to a Realm, then the debug output works fine.

@markst
Copy link

markst commented May 2, 2017

On further investigation it appears LinkingObjects doesn't return any results for unmanaged objects, can I get confirmation?

@bdash
Copy link
Contributor

bdash commented May 2, 2017

Correct, LinkingObjects always returns an empty collection for unmanaged objects.

In the future, please file a new issue rather than tacking your question onto an issue that's been closed for many months.

@markst
Copy link

markst commented May 2, 2017

@bdash so be it. I thought you'd prefer to keep issues to a minimum!

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