Add support for cascading deletes

[alazier]

Blocked on support in core.

[vittoriom]

Is this still in the works?

[jpsim]

Is this still in the works?

Yes, we'll post here as soon as we have something to share.

[obrhoff]

Anything new about this Issue / Feature. It's really hard to keep the database consistency with this feature missing.

[jpsim]

Looks like this is working well in core now (as of https://github.com/realm/realm-core/pull/867), so it should just be a matter of exposing it through the Objective-C & Swift APIs.

[effzehn]

Any estimation on how long until this feature is implemented and exposed?

[AliSoftware]

Interested in this as well :)

[mrackwitz]

We're currently actively working on a last conceptual question around this issue in core, which we want to see resolved so that we're able to keep the related APIs as intuitive as possible. We can't give yet an exact ETA, but we'll keep you posted with our further progress and are looking forward to be able to expose it as much as you.

[siuying]

That would definitely helpful.

[com314159]

I have write a Helper , you can just delete all the object with one line code. I just read all the Realm property value and delete it. maybe it will help you. check out at :https://github.com/com314159/RealmDeleteCascad

[RLMHelper deleteModelCascad:model inRealm:realm];

[vittoriom]

Looks interesting, but not exactly "safe to use" in a production environment with thousands of users :D

[bawn]

+1

[o15a3d4l11s2]

+1

[santihbc]

+1

[pusolito]

Any update on this issue? This feature is one of the big factors holding me back from adopting Realm.

[ghost]

If that helps anyone, I'm using an alternative approach in the mean time: a kind of garbage collection. The idea is that there's a realm entity called RootClassIdentifier each entry of which contains the name of a class that definitely needs to stay in the DB. Starting from the objects of those classes the tree is gradually copied into a temporary realm. When that's done, the old realm is deleted and the new one is used. I'm aware there should be performance issues if the number of objects to be kept increases drastically, but so far in my use case it takes less than one second. If this ever becomes a problem I'll just start to perform it less often, like on each 10 app runs. Here's a sample code:

- (void)performGarbageCollection {
    NSDate *startOfGCDate = [NSDate date];
    NSError *error;
    NSString *temporaryRealmName = @"tmp";
    // Rename all realm files to tmp
    [self.realm writeCopyToPath:... error:&error]; //generate path to temporaryRealmName
    [self.realm beginWriteTransaction];
    [self.realm deleteAllObjects];
    [self.realm commitWriteTransaction];

    // move the data
    RLMRealm *sourceRealm = [OFMObjectCache realmForDomain:temporaryRealmName];

    [self.realm beginWriteTransaction];
    RLMResults *rootClasses = [RootClassIdentifier allObjectsInRealm:sourceRealm];
    for (RootClassIdentifier *rootClassIdentifier in rootClasses) {
        Class aClass = NSClassFromString(rootClassIdentifier.className);
        for (id object in [aClass allObjectsInRealm:sourceRealm]) {
            [aClass createOrUpdateInRealm:self.realm withObject:object];
        }
    }
    [self.realm commitWriteTransaction];
    sourceRealm = nil;

    NSFileManager *fm = [[NSFileManager alloc] init];
    NSString *pathForTmp = ...;//get the path to the tmp realm

    NSDirectoryEnumerator *enumerator = [fm enumeratorAtPath:pathForTmp];
    // Remove tmp files
    for (NSString *fileName in enumerator) {
        NSString *absoluteString = [pathForTmp stringByAppendingPathComponent:fileName];

        BOOL isDirectory = NO;
        [fm fileExistsAtPath:absoluteString isDirectory:&isDirectory];
        if (!isDirectory) {
            NSRange range = [fileName rangeOfString:temporaryRealmName];
            if (range.location != NSNotFound) {
                BOOL result = [fm removeItemAtPath:absoluteString error:&error];
                if (!result) {
                    // handle error
                }
            }
        } else {
            [enumerator skipDescendants];
        }
    }
    NSDate *endOfGCDate = [NSDate date];
    NSLog(@"Garbage collection took %.3lf", [endOfGCDate timeIntervalSinceDate:startOfGCDate]);
}

Adding root classes goes like this:

[self.realm beginWriteTransaction];
[self.realm addOrUpdateObject:[[OFMRootClassIdentifier alloc] initWithClassName:NSStringFromClass(self.class)]];
[self.realm commitWriteTransaction];

And happens in the init method of classes that have as data models any of those root entities. I hope this makes sense. So far it seems to work well for me, although I'd drop this approach in a blink if cascading deletions would be available.

[nootfly]

+1, I switch back to Core Data. At least Core Data supports cascading delete.

[o15a3d4l11s2]

+1

[mrackwitz]

Update on this: As some might now, we had a first concept implemented in Core and initially thought that this would be sufficient. But after further discussions across the teams, it turned out that this concept has some drawbacks and is not always intuitive in its effects. For that reason we're working on a new concept which eliminates those drawbacks, but won't feel foreign in all supported host languages.

Why are we so cautious about this?

Because once we ship a concept, any change away from this would be difficult to introduce. It would be a breaking semantic change. This means that just by updating the version of Realm's frameworks the exactly same code would still compile, but could behave completely differently. This is an extremely undesirable situation, because in comparison to a conventional breaking syntactic change there is no easy way to see all the places where affected APIs changed. So we want to be very clear, that the concept we ship is the one we want to further follow.

[o15a3d4l11s2]

Thank you for the update and for the great work of the whole team!

[jasper-chan]

@mrackwitz Would you happen to know if there is an ETA as to when this feature is expected to be delivered to production?

[mrackwitz]

@jasper-chan: No, sorry there is no ETA yet. But I'll keep you posted here as soon as there is more to tell.

[geoherna]

Awesome. Glad to see it is being worked. Thanks guys!

[liangfenxiaodao]

I created a CascadingDeletable protocol like this:

protocol CascadingDeletable {
  func childrenToDelete() -> [AnyObject?]
}

and then got some of the objects conforming to that protocol like this:

extension Agency: CascadingDeletable {
  func childrenToDelete() -> [AnyObject?] {
    return [_address, logos]
  }
}

then I created a cascadingDelete function to delete everything recursively:

func cascadingDelete(object: AnyObject?) {
    if let deletable = object as? CascadingDeletable {
      deletable.childrenToDelete().forEach{ child in
        cascadingDelete(child)
      }
    }

    if let realmArray = object as? RLMArray {
      let array = realmArray.flatMap{$0}
      array.forEach { item in
        cascadingDelete(item)
      }
    }

    if let realmObject = object as? RLMObject {
      transactionWithBlock { [weak self] in
        self?.realm.deleteObject(realmObject)
      }
    }
  }

[o15a3d4l11s2]

I am using almost the same approach ( but written in Objective-c ) in one of my projects and it works like a charm.

[Ashok28]

It's been almost 2 years since opening this feature request, any ETA? I was really surprised when I found out this feature is missing, have to stick with Core Data for now...

[meilers]

@xiaodao Have you tried the cascadingDelete function with List? It's not working for me. List can't be cast to RLMArray.

[liangfenxiaodao]

@meilers you can just add another check for List

[meilers]

@xiaodao Yeah, I tried that. The casting still doesn't work because I don't know the generic type that will be used for List. And List

[JadenGeller]

@meilers List<Object> can not store subclasses of Object, only instances of Object itself. It's a current limitation of Realm. Read more about it here https://github.com/realm/realm-cocoa/issues/1109.

[JadenGeller]

@meilers Why do you not know the generic type of List?

[meilers]

@JadenGeller It's not that I don't know it - it's that I wish I could make @xiaodao's function reusable for any object I have.

[JadenGeller]

I think if you extend Object and List to conform to CascadingDeletable in an extension (rather than putting all that logic in the function), you could make it work.

Edit: You'd also have to change the CascadingDeletable protocol slightly. Let me give an example.

[meilers]

@JadenGeller you're absolutely right.

[JadenGeller]

Did you figure it out, or would you still like an example?

[meilers]

I can't test it now - but I will. No need for an example unless you want to share with others.

[runloop]

Definitely interested in this. For now I'll try and adopt the CascadingDeletable approach as it's better than what I'm currently doing.

[havocked]

An example with List would be greatly appreciated ! :)

[matouka-suzuki]

Hello!

I've tried to implement @xiaodao's approach and @JadenGeller's extension. How do you think about it?

func cascadingDelete(object: AnyObject?) {
    if let deletable = object as? CascadingDeletable {
      deletable.childrenToDelete().forEach{ child in
        cascadingDelete(child)
      }
    }

    if let realmObject = object as? Object {
        try! realm.write({
            realm.delete(realmObject)
        })
    }
}

extension List: CascadingDeletable {
      public func childrenToDelete() -> [AnyObject?] {
          return self.flatMap{ $0 }
      }
}

P.S. I saw a following problem in extension.

fatal error: array cannot be bridged from Objective-C

I've worked around by using 'for-in'

var array = [AnyObject?]()
for i in self {
 array.append(i)
}
return array

Thanks!

[gregpardo]

Here's my implementation in Swift 3. Supports List, Array, and Results also. Also supports passing an optional parameter of 'cascade' to the delete method. This allows more flexibility if you want the ability to choose upon deletion. No guarantees of speed.

https://gist.github.com/gregpardo/93420647700d31e2a9b10ed7b309cf96

[kimdv]

@mrackwitz is there any ETA for this feature?

[danielgalasko]

@kimdv in fairness its trivial to implement yourself, others have posted solutions above ☝️ But I guess framework level support could be cool

[AnthonyMDev]

The CascadingDeleteable solution is nice, but the problem is that you are still able to call the old delete(_:) method that doesn't cascade your deletes. If I have a cascading rule, it should guarantee that the delete is ALWAYS cascaded.

This method is error prone and can easily lead to bug later down the road.

We really need support for this internally for this reason.

[anfriis]

The example on a Cascading deletion method that @gregpardo posted is broken in Realm v2.7.0. If you have an object that has a List property, the objects in the List are not deleted using the extension methods.

Does anyone have a solution to this, or another approach on how to solve it, without having to do it the manual way, with is hard to maintain and error prone?

[demensdeum]

Some dirty hacks, use with care.

import Realm

let realm = try! Realm()

realm.write {        
 deleteObjectAndChilds(realmObject)
}

func deleteObjectAndChilds(_ entity: Any) {
    let realm = try! Realm()
    let mirror = Mirror(reflecting: entity)

    for property in mirror.children {
        if let entity = property.value as? Object {
            deleteObjectAndChilds(entity)
        }
        else if let list = property.value as? RealmSwift.ListBase {
            while list.count > 0 {
                let item = list._rlmArray.firstObject()
                deleteObjectAndChilds(item as Any)
            }
        }
    }

    // delete object

    if let realmEntity = entity as? Object {
        if realmEntity.isInvalidated == false {
            realm.delete(realmEntity)
        }
    }
}

[danurna]

Inspired by @demensdeum's solution I came up with something similar but without the use of Mirror. My solution deletes even referenced optional Objects. Feel free to give it a try and to provide feedback: https://gist.github.com/danurna/2207f1c480e2cee85fcd3491cd9d3707

[nirinchev]

As far as I can tell, both of these approaches will result in an endless loop when there's a circular relationship. I'm not proficient in swift, but here's some pseudocode that should work around this:

func cascadeDelete(_ entity: RLMObjectBase) {
    let toDelete = Set<RLMObjectBase>()
    toDelete.add(entity)
    while(!toDelete.isEmpty) {
        let current = toDelete.remove(0)
        if (!current.invalidated) {
            foreach (let property in current.objectSchema.properties) {
                if let value = current.value(forKey: property.name) {
                    if let related = value as? RLMObjectBase {
                        toDelete.add(related)
                    } else if let list = value as? RealmSwift.ListBase {
                        foreach (let related in list) {
                            toDelete.add(related)
                        }
                    }
                }
            }

            self.delete(entity)
        }
    }
}

The only change here is that nodes are removed as soon as they are encountered rather than after their related objects have been removed. I've used a Set<> under the assumption that RLMObjectBase is hashable, but if that's not the case, any collection will do.

[krodak]

Firstly, thanks everyone for all the effort and code snippets 👏 Just to update on @nirinchev with working Swift 4 example, wrapped in protocols and with lower cyclomatic complexity. So far I found this as the most reliable workaround, but of course, it doesn't solve the problem. Hope someone will find this useful 🙂

https://gist.github.com/krodak/b47ea81b3ae25ca2f10c27476bed450c

[Zhuinden]

Core support was added in https://github.com/realm/realm-core/pull/2752

[kubatruhlar]

I cannot wait to see it exposed through the API, keep us updated.

[karwa]

FYI for others following this issue - it's working its way up: https://github.com/realm/realm-object-store/pull/622