Implementing Ignoredproperties() on Both a Object Subclass and Its Own Subclass

Implementing ignoredProperties() on both a Object subclass and its own subclass

You've declared ignoredProperties as:

override static func ignoredProperties() -> [String]

It should be:

override class func ignoredProperties() -> [String]

static functions cannot be overridden by subclasses. class functions can.

Marking an open method final in subclass

You can do this by making the method public like this:

open class A { // This class is from the SDK and cannot be modified in anyway.
    open func aFunc() {}
}

open class B : A { // This has to be open for others to override.
    override final public func aFunc() {}
}

open keyword is for letting subclasses from different module to override, whereas the public keyword only gives access to different module and do not allow the overriding. If you want to override this method in only your module and not in other modules you can just make it public without final.

Swift override all setters and getters of a subclass

There is one hack to kind of attain what the poster is looking for, however possibly not advisable... Anyway; you can can create your own assignment operators that does whatever you want to do in realm prior to assigning the values

class MyType {        
    var myInt : Int = 0
    var myString : String = ""

    init(int: Int, string: String) {
        myInt = int
        myString = string
    }
}

infix operator === {}
func ===<T>(lhs: T, rhs: T) -> T? {
    Realm() // replace with whatever Realm()-specific stuff you want to do
    return rhs
}

protocol MyAddableTypes {
    func + (lhs: Self, rhs: Self) -> Self
}

extension String : MyAddableTypes {}
extension Int : MyAddableTypes {}

infix operator +== {} // ... -== similarily
func +==<T: MyAddableTypes>(lhs: T, rhs: T) -> T? {
    Realm() // replace with whatever Realm()-specific stuff you want to do
    return lhs+rhs
}

func Realm() {
    // ...
    print("Called realm")
}

var a = MyType(int: 1, string: "foo")
a.myString === "bar" // calls Realm(). After operation: a.myString = "bar"
a.myInt +== 1 // calls Realm(). After operation: a.myInt = 2

---

I thought I'd also mention that if you only want to do "Realm stuff" when a value is set (from your example: prior to setting a value, specifically), then the willSet method, used with stored properties, doesn't need to look so messy (nested closures), and personally, I would prefer this method

func Realm() {
    print("Called realm")
}

class MyType {

    // This isn't so messy, is it?
    var myInt : Int = 0 { willSet { priorToSetValue(newValue) } }
    var myString : String = "" { willSet { priorToSetValue(newValue) } }
    var myDouble : Double = 0.0 { willSet { priorToSetValue(newValue) } }

    private func priorToSetValue<T> (myVar: T) {
        // replace with whatever Realm()-specific stuff you want to do,
        // possibly including doing something with your new value
        Realm()
    }

    init(int: Int, double: Double, string: String) {
        myInt = int
        myDouble = double
        myString = string
    }
}

var a = MyType(int: 1, double: 1.0, string: "foo")

a.myString = "bar"
print(a.myString) // calls Realm(). After operation: a.myString = "bar"
a.myInt += 1 // calls Realm(). After operation: a.myInt = 2

Perform migration by adding List() and another model class

Edited After Receiving Clarification

Alrighty. So since you do want to pre-populate areas when you add it to your model, you will need to implement some logic in your migration block after all.

let migrationBlock: MigrationBlock = { migration, oldSchemaVersion in
    migration.enumerate(Region.className()) { oldObject, newObject in
        if oldSchemaVersion < 1 {
            let areas = newObject?["areas"] as? List<MigrationObject>
            // Add new objects to 'areas' as needed
        }
    }
}

There's some sample code showing how to handle List objects in migrations in Realm Swift's sample code collection

If your goal in adding a region property to Area is so you can find out which Region object this Area is a child of, then you don't need to implement that as a model property. Instead, you can use linkingObjects(_: forProperty: ) to have Realm work that out on your behalf.

class Area: Object {
    dynamic var id = 0
    dynamic var name = ""
    var regions: [Region] {
        return linkingObjects(Region.self, forProperty: "areas")
    }

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

To confirm what I said in the comments, migrations are a one-way path. They cannot be downgraded to previous schema versions. If you want to rapidly debug the migration process on a Realm file, I recommend putting the original Realm file aside and working on copies.

---

Original Answer

Do you actually have any data you wish to add to these new properties? Since it doesn't look like you do, you shouldn't need to implement any code in the migration block.

Simply increase the Realm schema version number, and supply an empty migration block.

let config = Realm.Configuration(
    schemaVersion: 1,
    migrationBlock: { migration, oldSchemaVersion in  

})

Realm.Configuration.defaultConfiguration = config

While the migration block cannot be nil, you only need to put code in there if there's any data in an old Realm file that you want to manipulate during a migration (i.e., moving it to another property). If you're adding brand new properties, it's not necessary to do anything to them inside the migration block.

It takes a little while to get into the mindset of Realm migrations, but thankfully once you do, you realise they're easier than you thought. :)

(Disclaimer: I work for Realm, but I use it in one of my own shipping iOS apps, where I've played with multiple migrations on real user data at this point. :) )

Do not map Realm object into Realm table

You'll want to override +[RLMObject shouldIncludeInDefaultSchema]. From Realm's source:

// Returns whether the class is included in the default set of classes persisted in a Realm.
+ (BOOL)shouldIncludeInDefaultSchema;

Realm Swift Error: Cycles containing embedded objects are not currently supported

It turns out using a different EmbeddedObject type for the list element of ChildObject’s children property will solve this issue. The solution looks like this:

final class ChildObject: EmbeddedObject {
    // Use `GrandChildObject` instead of `ChildObject` for `List.Element`.
    let children = List<GrandChildObject>()
}

final class GrandChildObject: EmbeddedObject {
    // ...
}

Just make sure to avoid using the same type in GrandChildObject, as it seems to be a limitation of EmbeddedObject. For example, don't do this:

final class GrandChildObject: EmbeddedObject {
    @objc dynamic var child: GrandChildObject?
}

Override @JsonIgnore in a subclass

You're introducing a second field named lastUpdated with this declaration

@Column(name = "LastUpdated")
private Date lastUpdated;

in your subtype MyEntity. I'm not sure how the database mapper handles this, but it seems redundant to me.

I can see two options.

One, get rid of this new field and have your overriden getLastUpdated method delegate to its super implementation. For example

@Override
@JsonIgnore(false)
@JsonProperty
public Date getLastUpdated() {
    return super.getLastUpdated();
}

When serializing a MyEntity object, Jackson will discover a single property through this accessor, lastUpdated, and use it to generate the JSON. It'll end up retrieving it from the superclass.

Two, use the class annotation @JsonIgnoreProperties to mark the ignored properties in the superclass

@JsonIgnoreProperties("lastUpdated")
abstract class StandardTimeStamp {

then clear (or add different values to) that "list" in the subclass

@JsonIgnoreProperties()
class MyEntity extends StandardTimeStamp implements Serializable {

Jackson will only use the annotation on the subclass, if it's present, and ignore the annotation on the superclass.

---

Related Topics