Markus Junginger

The swift database – ObjectBox Swift 1.0 Released

by Markus | Sep 24, 2019 | Mobile Database, ObjectBox, Release, Swift

Update: newer versions have been released. Check the changelog.

ObjectBox Swift 1.0 is here! Since the first public alpha released 10 months ago, we’ve worked hard and made major changes to put Swift first, tune the performance, and iterate on the API. We hope you love the result and appreciate your feedback.

All of this, to bring you the features you expect from a database, but more importantly – the features that we think delight developers and sets ObjectBox apart from other databases out there. Let’s swiftly (cheap pun intended) dive into ObjectBox Swift 1.0:

Built with Swift in Mind

// objectbox: entity
class Olympian {
    var id: Id = 0
    ...
}

let store = try Store(directoryPath: dbURL.path)
let box = store.box(for: Olympian.self)
let olympians: [Olympian] = try box.all()
let goldMedalist: Olympian = try box.get(sarahHoefflinId)

1

2

3

4

5

6

7

8

9

10

// objectbox: entity

class Olympian {

var id: Id = 0

...

}

let store = try Store(directoryPath: dbURL.path)

let box = store.box(for: Olympian.self)

let olympians: [Olympian] = try box.all()

let goldMedalist: Olympian = try box.get(sarahHoefflinId)

ObjectBox isn’t just a database bolted onto Swift. Your database entities are regular Swift classes or structs that you devise. No need to subclass a particular class (as with CoreData’s NSManagedObject), nor to write tedious serialization code. ?

All you need to do is add one property for the unique ID, build your project, and ObjectBox’s code generator will write a little bit of code for you, just like the Swift compiler does for Codable objects. All that’s left then, is to call a simple method like put() on the object to write it out:

try box.put(ruthJebet)

1	try box.put(ruthJebet)

We’ve tried to keep this simplicity throughout the Swift binding, e.g. making it very easy to use any RawRepresentable enum without writing any conversion code.

Automatic Schema Migrations

A common chore with databases is schema migration. ObjectBox takes care of that. If you add a new property or class there are no additional migration steps required. Old objects will keep working, and new objects will be saved with the additional fields. Similarly, adding new classes will add them to the database without any error-prone migration steps.

Moreover, you do not need to maintain a dedicated schema, because your classes and structs are the schema in the first place.

Relations

class Author: Entity {
    var id: Id = 0
    var name: String
    var books: ToMany<Book> = nil
    ...
}
amandaPalmer.books.append(theArtOfAsking)
try amandaPalmer.books.applyToDb()

1

2

3

4

5

6

7

8

class Author: Entity {

var id: Id = 0

var name: String

var books: ToMany<Book> = nil

...

}

amandaPalmer.books.append(theArtOfAsking)

try amandaPalmer.books.applyToDb()

To ensure ObjectBox knows how to save object references, you use a wrapper class. Either ToOne or ToMany, instead of a straight reference or an array. This lets ObjectBox lazily load the related objects from the database, only when you’re actually accessing a related object.

The Swift 1.0 release brings you our complete set of relations: One-to-many, many-to-many, and their corresponding back-links. ToMany behaves just like any other Swift collection, you can add or remove objects as you please with your familiar methods like append().

Queries

let query = try box.query { Author.fname == "Jeaniene" }.build()
let results = try query.find() // All Authors matching query.
// All last names of the matching authors:
let names = try query.property(Author.lname)
                     .distinct().findStrings()

1

2

3

4

5

let query = try box.query { Author.fname == "Jeaniene" }.build()

let results = try query.find() // All Authors matching query.

// All last names of the matching authors:

let names = try query.property(Author.lname)

.distinct().findStrings()

Of course ObjectBox lets you perform queries to collect data; either complete objects or individual properties (basic Swift data types).

But with ObjectBox you don’t mess around with query strings or unpack data from cursors. You simply write Swift expressions with function calls and operators you’re already used to.

Also, you get to keep the type-safety guarantees and compile-time checking. So you don’t have to spend hours figuring out why your query doesn’t return the proper results, just to discover you made a typo in a field name in a query string.

subscription = query.subscribe() { authors, error in
    if let error = error { self.reportError(error); return }
    self.authors = authors
    self.tableView.reloadData()
}

1

2

3

4

5

subscription = query.subscribe() { authors, error in

if let error = error { self.reportError(error); return }

self.authors = authors

self.tableView.reloadData()

}

ObjectBox lets you then operate on these objects, watch a query for changes, retrieve the results, delete the objects matching a query etc. The source code even contains a file that adds Combine support so you can integrate with its pipelines to take advantage of Apple’s newest technology.

Open Source Swift Binding

If you’re curious how things work behind the scenes, feel free to check out the Swift source code. The Swift database source code, as well as our code generator based on Sourcery, are available among other projects through our Github account.

How-to Get Started

It’s a matter of minutes to get started with ObjectBox. Check our setup instructions (based on CocoaPods) and jump right into code with the getting started guide.

Your Feedback. And what’s Next?

As always, we would love to hear your feedback! Do you like ObjectBox as much as we do? We put our hearts in this product and are excited to learn your thoughts: What features are you most excited about, what are we missing?

We haven’t written much about a topic very dear to us: performance. We will cover this in a follow up post. Also, look forward to our ObjectBox Swift 1.0 benchmarks, which we will release soon including the sources.

——

Looking for a fast and simple data synchronization solution?

Sign Up for ObjectBox Early Alpha >>

Objectively Swifter Database: How Swift + C outperform Objective-C

by Markus | May 14, 2019 | Mobile Database, ObjectBox, Release | 2 comments

We’ve been optimizing ObjectBox for speed right from the beginning, making it the fastest database for edge computing around. However, the fastest library in the world is useless if its interface to your language isn’t optimized for that language’s strengths and weaknesses. The 0.8.0 release of ObjectBox for Swift gives you a nearly 70% performance boost out of the box by improving the way we integrate with Swift:

How did we Achieve this Speed-Up?

When we created ObjectBox’s Swift binding, we did not have our C API yet. So, to bridge between the C++ database core and Swift, we implemented a number of classes using Objective-C++. Objective-C++ is neat: it looks to Swift like Objective-C (so like a Swift class), but will happily call into C++ code.

Objective-C is also a very different language from Swift, and particularly generics and structs don’t have a direct equivalent in Objective-C. So when we realized that many reactive frameworks in Swift were built around structs, we decided to change gears. We rewrote a number of core Objective-C classes in the Swift binding as Swift classes on top of the C API that we now use in all our newer language bindings, eliminating a lot of Objective-C’s dynamic dispatch, and generally improving upon algorithms here and there.

The main goal was to give our users struct support and lay the groundwork for taking advantage of Swift 5.1’s upcoming UTF8 strings by eliminating use of the UTF16-based NSString. We also wanted to bring ObjectBox’s Objective-C-beholden error handling in line with Swift conventions. So we expected modest speed-ups here and there, but a speed increase this noticeable even before Swift 5.1 was a pleasant surprise, and we wanted to get these improvements into our users’ hands as quickly as possible.

Using structs with ObjectBox

One rather unique aspect of Swift compared to other languages is how Swift defines the term struct as value type and class as reference type. That makes structs incredibly handy for cases where you want to guarantee an object can never change.

Thread-safety, for instance: if you know an object is unchangeable, there is no chance of race conditions while editing. You need no locks, no copies; your threads can all safely operate on the same memory.

However, when you put an object into your ObjectBox database, put(_:)updates the object’s id property to establish the association between the database entry and your object in memory. ObjectBox can’t do that with unchangeable structs, so we needed to make a slight adjustment to ObjectBox’s usual simple put(_:) flow:

 struct User {
    let id: Id<user>
    let name: String
    let admin: Bool
}

let myUser = User(id: 0, name: "Kathryn Drennan", admin: true)
let savedUser = box.put(struct: myUser)</user>

1

2

3

4

5

6

7

8

struct User {

let id: Id<user>

let name: String

let admin: Bool

}

let myUser = User(id: 0, name: "Kathryn Drennan", admin: true)

let savedUser = box.put(struct: myUser)</user>

Missed the difference? It’s tiny: You use put(struct:) instead of the regular put(_:). put(struct:) will create a copy of the struct you gave it with the ID changed to whatever ID the object was assigned in the database (the copy is what we store in savedUser in the above example).

So, what if you want to make changes? The way you change immutable structs is to make a copy with the one thing you wanted to change set to a different value. So while you could save it to the database using put(struct:), you already made a copy of the object, and it will not change after being saved, because it already has an ID. Won’t that second copy be wasteful?

That’s why Box now also offers putImmutable(_:). If you know that your object has already been saved, and you don’t need a copy. Just call putImmutable(_:). instead of put(struct:).

let myUser = users.first
let savedUserID = box.putImmutable(myUser)
// assert(myUser.id == savedUserID)

1

2

3

let myUser = users.first

let savedUserID = box.putImmutable(myUser)

// assert(myUser.id == savedUserID)

This will return the ID for your convenience, but you can always ignore it, if you do not need it.

What else has changed?

While we’re always improving things under the hood, not much should change for your existing ObjectBox code. Apart from the new ObjectBoxError enum replacing the janky old Objective-C-style OBXError... classes, your existing code should just compile. All the changes are in the generated code.

Go give it a try, and let us know how we’re doing.

ObjectBox Swift for iOS and macOS

by Markus | Nov 28, 2018 | Release | 1 comment

We’re happy to share our first Swift version of the ObjectBox database for iOS and macOS! We want to give you a Swift “native” API without any ObjectiveC legacy shining through, which is why we decided to put Swift, with its unique language features, first. We really want your feedback on this to improve swiftly, for example on our query API (more details below):

let joes = box.query{ Person.name.contains("Joe") }

1	let joes = box.query{ Person.name.contains("Joe") }

(more…)

ObjectBox C API for IoT

by Markus | Nov 12, 2018 | Release

The ObjectBox C API is here, as requested by IoT C/C++ developers. ObjectBox’s efficiency is a perfect match for the Internet of Things with its resource-restricted devices and need for offline capability.

(more…)

ObjectBox 2.2 comes with important fixes

by Markus | Oct 8, 2018 | Release

We released ObjectBox 2.2 for Android more than a week ago: It comes with important fixes and we advise to update to the latest version asap. We noticed that already fixed issues are still being reported. Thus, we decided to dedicate a small blog post to increase the awareness for the two most important fixes:

(more…)