肇鑫的技术博客

业精于勤,荒于嬉

Realm的坑(三)

上一个坑里,Realm的坑(二),我们使用非受管对象避开必须使用写入交易的问题。但是,每次使用时都要设置属性还是挺麻烦的。我们寻求一种可以一劳永逸的方式。

最初的想法

我最初想到的是利用NSCopying协议,然后利用Object对象的properties属性给Object实例的属性赋值。如:

extension Object:NSCopying {
    public func copy(with zone: NSZone? = nil) -> Any {
        let o = Object()
        for p in objectSchema.properties {
            let value = self.value(forKey: p.name)
            switch p.type {
            case .linkingObjects:
                break
            default:
                o.setValue(value, forKey: p.name)
            }
        }
        
        return o
    }
}

由于NSCopying的返回值是Any,因此,在使用时需要转换,像这样:

let anotherBar = bar.copy() as! Foo
  
try! realm.write {
    realm.add(anotherBar, update:true)
}

但是这里发生了一个问题。当前版本的Realm中有一个错误,不能在swift中直接创建Object(),程序会崩溃。因此我提交了一个issue

进阶

既然不能直接使用Object(),我决定使用通用类型的函数,像这样:

func unmanagedCopy<T>(of i:T) -> T where T:Object {
    let o = T()
    for p in i.objectSchema.properties {
        let value = i.value(forKey: p.name)
        switch p.type {
        case .linkingObjects:
            break
        default:
            o.setValue(value, forKey: p.name)
        }
    }
    
    return o
}

let anotherBar = unmanagedCopy(of: bar)
  
try! realm.write {
    realm.add(anotherBar, update:true)
}

这么做,带来一个好处,就是我在具体使用的时候不用进行类型转换了。缺点就是这是一个全局函数,也许放到一个struct里会更好一些?

最终的解决方案

在上面提单的issue里,**JadenGeller**给了我两个很好的建议。下面的代码是最终的解决方案。

// MARK: - UnmanagedCopy Protocol
protocol UnmanagedCopy {
    func unmanagedCopy() -> Self
}

extension Object:UnmanagedCopy{
    func unmanagedCopy() -> Self {
        let o = type(of:self).init()
        for p in objectSchema.properties {
            let value = self.value(forKey: p.name)
            switch p.type {
            case .linkingObjects:
                break
            default:
                o.setValue(value, forKey: p.name)
            }
        }
        
        return o
    }
}

首先建立一个UnmanagedCopy的协议。虽然直接写这个函数也可以,但是建立协议可以使函数的目的更加明确。

然后在Object对象的扩展里实现了这个协议。这里用let o = type(of:self).init()避开了不能使用Object()的问题,变量o的类型是Self。函数返回值类型Self可以确保最终的类型与self的实际类型相同,这就保证了使用时不必再进行二次转换。具体使用:

let anotherBar = bar.unmanagedCopy()
  
try! realm.write {
    realm.add(anotherBar, update:true)
}

这个函数已经基本够用了,它包含你的实例里所有持久性数据的属性,但是不包括ignore函数里包含的属性public class func ignoredProperties() -> [String]。所以,如果你有额外的需求,就应该在Object的子类里重写这个函数。如:

class Foo:Object {
    dynamic var id:Int = 0
    dynamic var name:String = ""
    dynamic var age:Int = 8
    
    var temp = "temp value"
    
    override class func ignoredProperties() -> [String] {
        return ["age", "temp"]
    }
    
    override class func primaryKey() -> String? {
        return "id"
    }
    
    override func unmanagedCopy() -> Self {
        let o = type(of:self).init()
        for p in objectSchema.properties {
            let value = self.value(forKey: p.name)
            switch p.type {
            case .linkingObjects:
                break
            default:
                o.setValue(value, forKey: p.name)
            }
        }
        
        o.age = age
        o.temp = temp
        
        return o
    }
}

有关Self的更多用法,看Self的用法

相关

Realm的坑(一)
Realm的坑(二)
Realm的坑(三)
Realm的坑(四)

Realm的坑(二)

managed与unmanaged

我们都知道,变量都有其生命周期。当存在变量的强引用时,变量会一直存在。比如,有

struct Foo {
   var name:String
}
let bar = Foo(name:"John")

bar在赋值后一直存在。我们始终都可以使用bar.name来获得name属性的值John。但是在Realm中一切都变得不一样了。在Realm中,你通过子类继承Object对象来构建你的Model。然后通过Realm.add来添加这个子类的实例到Realm中。

class Foo:Object {
    dynamic var name:String = ""
}
let bar = Foo()

let realm = try! Realm()
try! realm.write {
	realm.add(bar)
}

你新建出来的bar是unmanaged的实例。realm.add(bar)之后,bar就是managed的实例了。一旦受管,该实例的用法就不能再那么随心所欲了,之后对它的操作就必须在Realm的交易里完成。如:

let bar = Foo()
bar.name = "Marry" // ok

let realm = try! Realm()
try! realm.write {
	realm.add(bar)
	bar.name = "Kelly" // ok
}

bar.name = "Jimmy" // *** Terminating app due to uncaught exception 'RLMException', reason: 'Attempting to modify object outside of a write transaction - call beginWriteTransaction on an RLMRealm instance first.'

为什么name被设置成Marry和Kelly的时候没问题,但是一设置成Jimmy就不行了呢?

  1. 这是因为bar的状态发生了改变。在realm.add()之前,bar是非受管的状态,此时bar在Realm数据库中没有记录。它的行为和一般的类的实例类似,因此可以直接设置name
  2. realm.add()之后,bar在数据库中有了记录,变成了受管的状态,此时再更改它,就必须在realm的写入交易中完成。就像Kelly那样。
  3. Jimmy的部分,由于没有在写入交易中完成,程序会抛出异常并终止运行。

如果不想添加额外的写入交易,就需要添加新建一个非托管对象,然后在添加它到Realm,如:

let anotherBar = Foo()
anotherBar.name = bar.name
  
try! realm.write {
    realm.add(anotherBar)
}

这样的代码有一点儿问题。anotherBarbar对应的是两个不同的对象。现在数据库中同时存在baranotherBar对应的对象了。因此我们需要删除bar

let anotherBar = Foo()
anotherBar.name = bar.name
  
try! realm.write {
    realm.add(anotherBar)
    realm.delete(bar)
}

这很不环保。对于有主键的类的实例,可以使用add(object: Object, update: true),比如:

class Foo:Object {
    dynamic var id:Int = 0
    dynamic var name:String = ""
    
    override class func primaryKey() -> String? {
        return "id"
    }
}

let bar = Foo()
bar.id = 1
bar.name = "Marry" // ok

let realm = try! Realm() 
try! realm.write {
    realm.add(bar)
    bar.name = "Kelly" // ok
}
  
let anotherBar = Foo()
anotherBar.id = 1
anotherBar.name = bar.name
  
try! realm.write {
    realm.add(anotherBar, update:true)
}

每次还要重新设置非受管对象还是挺麻烦的,如果能直接生成一个就好了。这就是第三个坑。Realm的坑(三)

相关

Realm的坑(一)
Realm的坑(二)
Realm的坑(三)
Realm的坑(四)

Realm的坑(一)

Realm中常见的“Realm accessed from incorrect thread”问题的分析总结

Realm的Results中,有一个很有用的特性,叫做自动更新。顾名思义,就是这个结果会在使用时自动重新查询,已保证最新。当然,这也带来了新的问题。

一旦在创建该变量的线程之外使用该变量,就会导致程序崩溃。

比如,今天我就是在请求通知权限的代码中使用了tasks变量。结果导致程序崩溃。因为这个请求是调用了系统的请求,不是程序本身的线程。

解决办法

  1. 新建realm,重新查询
  2. 使用临时变量,而不使用Results的变量。
  3. 使用DispatchQueue.main.async,更改执行的thread。

备注

print(Thread.current) //可以调试当前的thread

相关

Realm的坑(一)
Realm的坑(二)
Realm的坑(三)
Realm的坑(四)