Release Archives - Page 2 of 6

Dart Flutter Database ObjectBox 1.0 Release

by Vivien | May 18, 2021 | Mobile Database, ObjectBox, Release

In 2019 we first introduced the ObjectBox database v0.1 for Flutter/Dart. Our team has loved the engagement and feedback we’ve received from the developer community since, and we’re thrilled to announce the first stable version 1.0 for ObjectBox Dart/Flutter today.

With this release we bring you the fast and easy to use ObjectBox database for Dart objects: optimized for high performance on mobile and desktop devices. ObjectBox persists your Dart objects (null safe, of course) and comes with relations, queries, transactions, and Data Sync. For a feature list and more, please also check the pub.dev page.

ObjectBox by Example

For those of you new to ObjectBox, here is how you can use it (or check the docs if you want to dive deep right away). By annotating a class with @Entity you tell ObjectBox that you want to persist its objects, which is done putting the object in a Box:

@Entity()
class Person {
  int id = 0;
 
  String firstName;
  String lastName;
 
  Person(this.firstName, this.lastName);
}
 
// Open a Store once and keep it open to get type specific Boxes
final store = Store(getObjectBoxModel());
final box = store.box<Person>();
 
// let’s put a new Person in the database
var person = Person("Marty", "McFly");
final id = box.put(person);

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

@Entity()

class Person {

int id = 0;

String firstName;

String lastName;

Person(this.firstName, this.lastName);

}

// Open a Store once and keep it open to get type specific Boxes

final store = Store(getObjectBoxModel());

final box = store.box<Person>();

// let’s put a new Person in the database

var person = Person("Marty", "McFly");

final id = box.put(person);

What’s new with the 1.0?

Version 1.0 delivers a stabilized API and adds new essential features like async writes and query streams. We’ve also extended support for Flutter desktop. Let’s look at queries and how they can be used depending on the use case:

 // find all people whose name starts with "Mc"; 1. Query variant
Query<Person> query = box.query(Person_.firstName.startsWith("Mc")).build();
List<Person> people = query.find();
 
// 2. variant: "watch" the DB for any changes in the entity, then rerun the query
Stream<Query<Person>> watchedQuery = query.watch();
// You can then .listen(), or for example add the query to a StreamBuilder to show on UI.
_controller.addStream(watchedQuery.map((Query<Person> q) => q.find()));
 
// 3. variant: stream data from (non-trivial) queries:
Stream<User> resultStream = box.query().build().stream();
await stream.forEach((Person person) => print(‘${person.firstName} ${person.lastName}’));

1

2

3

4

5

6

7

8

9

10

11

12

// find all people whose name starts with "Mc"; 1. Query variant

Query<Person> query = box.query(Person_.firstName.startsWith("Mc")).build();

List<Person> people = query.find();

// 2. variant: "watch" the DB for any changes in the entity, then rerun the query

Stream<Query<Person>> watchedQuery = query.watch();

// You can then .listen(), or for example add the query to a StreamBuilder to show on UI.

_controller.addStream(watchedQuery.map((Query<Person> q) => q.find()));

// 3. variant: stream data from (non-trivial) queries:

Stream<User> resultStream = box.query().build().stream();

await stream.forEach((Person person) => print(‘${person.firstName} ${person.lastName}’));

There are two new approaches to do async puts for asynchronous database writes: putAsync() returns a Future to check if the call was successful.

Future<int> idFuture = box.putAsync(person);
...
final id = await idFuture;
userBox.get(id); // after the Future completed, the object is stored in the database

1

2

3

4

Future<int> idFuture = box.putAsync(person);

...

final id = await idFuture;

userBox.get(id); // after the Future completed, the object is stored in the database

Or you can use a background queue if you don’t need individual Futures, the following code inserts 100 objects and only waits once:

for (int i = 0; i < 100; i++) {
  box.putQueued(Person(...));
}
store.awaitAsyncSubmitted();
// after `awaitAsync*`: objects are inserted
expect(box.count(), equals(100));

1

2

3

4

5

6

for (int i = 0; i < 100; i++) {

box.putQueued(Person(...));

}

store.awaitAsyncSubmitted();

// after `awaitAsync*`: objects are inserted

expect(box.count(), equals(100));

If you are interested in further improvements we made to 1.0, please check out the full changelog.

Dart Flutter Database Benchmarks

ObjectBox Dart v1.0 also comes with considerable optimizations bringing a new level of database performance to Flutter apps. ObjectBox enables data-heavy apps that were not possible on Flutter before. Consider this a first sneak-peek; stay tuned for detailed performance benchmarks to be released including queries (hint: they are really fast) along with updated benchmarking code.

What we tested

We looked at some two popular approaches: sqflite, a SQLite wrapper for Flutter (no Dart Native support), and Hive, a key-value store with Class-adapters which seems still popular although its creator abandoned it for architectural shortcomings (it has memory problems and does not support queries). In the previous benchmark we’ve also had a look at Firestore, but being an online-only database it was thousands of times slower than the rest so we’ve left it to rest this time around. Check our previous benchmark if you’re interested.

To get an overview of the databases, we tested CRUD operations (create, read, update, delete). Each test was run multiple times and executed manually outside of the measured time. Data preparation and evaluation were also done outside of the measured time.

ObjectBox, sqflite, Hive performance comparison across CRUD

Looking at the results, we can see ObjectBox performing significantly faster than sqflite across the board, with up to 100 time speed-up in case of create & update operations. Compared to Hive, the results are a little closer in some cases (read) though ObjectBox still comes out on top in all the metrics. Considering that Hive keeps all Dart objects in memory (!) while ObjectBox does not, should give you a good impression of how fast object persistence with ObjectBox is.

ObjectBox Database for Flutter/Dart Highlights

For those of you new to ObjectBox, here’s a quick summary of what our super-fast embedded database offers, out of the box:

automatic schema migration: adding new classes or fields just works
type-safe APIs, e.g. no interface{} arguments
embedded edge database – no server needed, store all data directly on the device
no ORM, no SQL
relations: to-one, to-many (eager and lazy fetching)
robust query support, including indexes for scalable lookups
Support for implicit (automatic) and explicit (user defined)
transactions: ACID compliant with superfast bulk/batch operations
low memory usage
runs across operating systems: 64-bit Linux, macOS, Windows, small 32-bit ARM-based Linux devices (e.g. Raspberry Pi)
Data Sync: an efficient and easy way to synchronize data between your app and the cloud

Getting Started with ObjectBox for Flutter/Dart Today

ObjectBox is free to use and you can get started right now with the Flutter database on GitHub, via the docs, pub.dev, or this getting-started video tutorial, or getting-started article.

We ❤️ your Feedback

Now it’s your turn: let us know what you love, what you don’t, what do you want to see next? Share your feedback with us, or check out GitHub and up-vote the features you’d like to see next in ObjectBox.

ObjectBox Dart/Flutter v0.11 Database: Performance & Relations

by Markus | Feb 2, 2021 | Benchmarks, Mobile Database, ObjectBox, Release | 4 comments

Flutter Databases are few. Therefore, we’re happy to take a big step towards 1.0 with this ObjectBox Dart v0.11 release, improving performance and bringing the much-desired relations support known from other ObjectBox DB language bindings to Dart/Flutter.

For those of you new to ObjectBox: ObjectBox is a superfast NoSQL object database for Flutter / Dart and here is how you can save data in your Dart / Flutter apps:

@Entity()
class Person {
  int id;

  String firstName;
  String lastName;
}

final store = Store(getObjectBoxModel());
final box = store.box<Person>();

var person = Person()
  ..firstName = "Joe"
  ..lastName = "Green";

final id = box.put(person);  // Create

person = box.get(id);        // Read

person.lastName = "Black";
box.put(person);             // Update

box.remove(person.id);       // Delete

// find all people whose name start with letter 'J'
final query = box.query(Person_.firstName.startsWith('J')).build();
final people = query.find();  // find() returns List<Person>

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

@Entity()

class Person {

int id;

String firstName;

String lastName;

}

final store = Store(getObjectBoxModel());

final box = store.box<Person>();

var person = Person()

..firstName = "Joe"

..lastName = "Green";

final id = box.put(person); // Create

person = box.get(id); // Read

person.lastName = "Black";

box.put(person); // Update

box.remove(person.id); // Delete

// find all people whose name start with letter 'J'

final query = box.query(Person_.firstName.startsWith('J')).build();

final people = query.find(); // find() returns List<Person>

To learn about more ObjectBox features, like relations, queries and data sync, check our ObjectBox pub.dev page.

How fast is ObjectBox Dart? Performance Benchmarks

Speed is important for data persistence solutions. Accordingly, we wanted to test how ObjectBox compares performance-wise to other Flutter Dart database options. Therefore, we looked for libraries with comparable levels of storage abstraction and feature set – so not just plain SQL/Key-value storage but also ORM-like features. There doesn’t seem to be that much choice…

We looked at some two popular approaches: sqflite a SQLite wrapper for Flutter (no Dart Native support), and Hive, a key-value store with Class-adapters which seems still popular although its technology is phased out (see below). As a third alternative we pulled in Firestore, which does not really fit as it is no local database, but would be fun to compare anyway.

What we tested

To get an overview of the databases, we tested CRUD operations (create, read, update, delete). Each test was run multiple times and executed manually outside of the measured time. Data preparation and evaluation was also done outside of the measured time.

We tried to keep the test implementations as close as possible to each other while picking the approaches recommended by the docs for each database. We open sourced the test code at https://github.com/objectbox/objectbox-dart-performance if you want to have a closer look.

Performance Benchmark Results

Looking at the results, we can see ObjectBox performing significantly faster than sqflite across the board, with up to 70 times speedup in case of create & update operations. Compared to Hive, the results are a little more varied, with Hive being faster at reading objects than ObjectBox (we come to that later in our outlook), and ObjectBox being faster at creating objects, about four times faster at updates and three times for deletes. As a mostly-online database, it becomes clear that Firestore’s performance is not really comparable.

Implementation notes

ObjectBox: This release largely boosted the performance. The remaining bottlenecks are due to Dart itself and how it allows to modify byte buffers. There’s potential to double the speed if we look at other languages supported by ObjectBox. And if that’s not happening soon, we’d still have the option to do some low-level hacks…

Sqflite: a wrapper around SQLite, which is a relational database without direct support for Dart objects. Each dart object field is mapped to a column in the database, as per sqflite docs, i.e. converting between the Dart class and a Map.

Hive: We’ve tested with the latest Hive release, which is technically discontinued. The author hit two architectural roadblocks (RAM usage and queries) and is currently in the process to do a rewrite from scratch.
Update: strictly speaking it’s not straightforward to directly compare e.g. ObjectBox vs. Hive. In Hive, the high read numbers result from Dart objects already cached in memory. If the objects are fetched using the async API from disk, the numbers drop by factor 1000.

Firestore: This is totally apples and oranges, but we still decided to include Firebase/Firestore as it seems at least somewhat popular to “persist data”. It’s quite Cloud centric and thus offers limited offline features. For example, in order to use batches (“transactions”), an internet connection is required to “commit”. Also, due to its low performance, the test configuration was different: batches of 500 objects and only 10 runs.

Test setup

We ran the benchmarks as a Flutter app on a Android 10 device with a Kirin 980 CPU. The app executed all operations in batches of 10.000 objects, with each batch forming a single transaction. Each test was run 50 times, averaging the results over all the runs. This ensured the VM warmup (optimization) during the first run and garbage collections don’t affect the overall result significantly. (We care about accurate benchmarks; read more about our benchmarking best practices here.)

Outlook

With this latest release, we’re not far away from a stable API for a 1.0 release (🎉), so please share your thoughts and feedback. For the next release, we’ll add features like async operations, more relation types and some smaller improvements. We are also working on an ObjectBox variant for the Web platform that is planned close to the 1.0 release. And of course there is ObjectBox Data Sync for Flutter/Dart. If you want to be first in line to try, drop us a line, we can put you on the shortlist.

ObjectBox Swift 1.4 – In Relation to…

by Markus | Sep 8, 2020 | ObjectBox, Release, Swift

ObjectBox for Swift 1.4 makes object relations more natural and intuitive for Swift developers. For example, let’s take the teacher-student relation to Swift and how you store objects in the database. Let’s say “Teacher” is a Swift class that has a collection called “students”. Now let’s say we have a new teacher with new students and want to store them in the ObjectBox database. It’s done like this:

let yoda = Teacher(name: "Yoda") yoda.students.append(Student(name: "Luke")) yoda.students.append(Student(name: "Anakin")) try box.put(yoda)

This is pretty much standard Swift. A single put command is enough to store all three new objects in the database (sorry for the “try”, Yoda, but you know, IO…). Now let’s see how this works. The students’ property in the Teacher’s class is of type ToMany<Student> and works like any Swift collection. This is because ToMany implements the protocols RandomAccessCollection and RangeReplaceableCollection. Under the hood however, it tracks all changes. Thus, when ObjectBox is instructed to put Yoda in a box, it also knows that two students were added. It also knows that our two Jedi students are new and thus puts them in database too. If you supply students that have been already persisted, it won’t put them. You can also mix new and existing objects.

Version 1.4 does not only bring TooMany (sic) improvements, but also brings a couple of new features, e.g. a bulk-get and read-only stores. You also may have heard of Sync (some kind of teleportation for objects, my young padawan). We’re still working on that, but we started to expose the Sync API with this release. It doesn’t come with any (space consuming) implementation so it’s really about getting early awareness and feedback. A full changelog is available at the docs.

So, time to start your (cocoa) pod again and let us know what you think. May the for… um, OK, that’s getting too many references for one article. One to many.

Time Series & Objects: Using Data on the Edge

by Vivien | Jun 30, 2020 | Edge Computing, Insights, IoT, Release, Time Series

Many IoT projects collect, both time series data and other types of data. Typically, this means they will run two databases: A time-series database and a traditional database or key/value store. This creates fracture and overhead, which is why ObjectBox TS brings together the best of both worlds in one database (DB). ObjectBox TS is a hybrid database: an extremely fast object-oriented DB plus a time-series extension, specially optimized for time series data. In combination with its tiny footprint, ObjectBox is a perfect match for IoT applications running on the edge. The out-of-the-box synchronization takes care of synchronizing selected data sets super efficiently and it works offline and online, on-premise, in the cloud.

What is time series data?

There are a lot of different types of data that are used in IoT applications. Time-series is one of the most common data types in analytics, high-frequency inspections, and maintenance applications for IIoT / Industry 4.0 and smart mobility. Time series tracks data points over time, most often taken at equally spaced intervals. Typical data sources are sensor data, events, clicks, temperature – anything that changes over time.

Why use time series data on the edge?

Time-series data sets are usually collected from a lot of sensors, which sample at a high rate – which means that a lot of data is being collected.

For example, if a Raspberry Pi gateway collects 20 data points/second, typically that would mean 1200 entries a minute measuring e.g. 32 degrees. As temperatures rarely change significantly in short time frames, does all of this data need to go to the cloud? Unless you need to know the exact temperature in a central location every millisecond, the answer is no. Sending all data to the cloud is a waste of resources, causing high cloud costs without providing immediate, real-time insights.

The Best of Both Worlds: time series + object oriented data persistence

With ObjectBox you aren’t limited to only using time series data. ObjectBox TS is optimized for time series data, but ObjectBox is a robust object oriented database solution that can store any data type. With ObjectBox, model your world in objects and combine this with the power of time-series data to identify patterns in your data, on the device, in real time. By combining time series data with more complex data types, ObjectBox empowers new use cases on the edge based on a fast and easy all-in-one data persistence solution.

Bring together different data streams for a fusion of data; mix and match sensor data with the ObjectBox time series dashboard and find patterns in your data. On top, ObjectBox takes care of synchronizing selected data between devices (cloud / on-premise) efficiently for you.

time-series-data-visualization-dashboard

Get a complete picture of your data in one place

Use Case: Automotive (Process Optimization)

Most manufacturers, whether they’re producing cars, the food industry, or utilities, have already been optimizing production for a long period of time. However, there are still many cases and reasons why costly manual processes prevail. One such example is automotive varnish. In some cases, while the inspection is automatic and intelligent, a lot of cars need to be touched up by hand, because the factors leading to the errors in the paint are not yet discovered. While there is a lot of internal expert know-how available from the factory workers, their gut feel is typically not enough to adapt production processes.

How can this be improved using time series and object data?

The cars (objects) are typically already persisted including all the mass customization and model information. If now, all data, including sensor data, of the manufacturing site like temperature, humidity, spray speed (all time-series data) is persisted and added to each car object, any kind of correlations between production site variables, individual car properties and varnish quality can be detected. Over time, patterns will emerge. The gut feel of the factory workers would provide a great starting point for analyzing the data to discover Quick Wins before longterm patterns can be detected. Over time, AI and automatic learning kicks in to optimize the factory setup best possible to reduce the need for paint touch ups as much as possible.

Use Case: Smart Grids

Utility grid loads shift continually throughout the day, effecting grid efficiency, pricing, and energy delivery. Using Smart Grids, utilities companies can increase efficiency and reliability in real time. In order to get insights from Smart Grids, companies need to collect a large volume of data from existing systems. A huge portion of this data is time series, e.g. usage and load statistics. On top, they incorporate other forms of data, e.g. asset relationship data, weather conditions, and customer profiles. Using visualization and analytical tools, these data types can be brought together to generate business insights and actionable operative goals.

ObjectBox TS: time series with objects

Storing and processing both time series data and objects on the edge, developers can gather complex data sets and get real time insight, even when offline. Combining these data types gives a fuller understanding and context for data – not only what happens over time, but what other factors could be influencing results. Using a fast hybrid edge database allows developers to save resources, while maintaining speed and efficiency. By synchronizing useful data to the cloud, real time data can be used for both immediate action, and post-event analysis.

Get in touch with our team to get a virtual demo of ObjectBox TS, or check out the sample GitHub repo to see more about the code.

Go to ObjectBox TS

Introducing: ObjectBox Generator, plus C++ API [Request for Feedback!]

by Markus | Jun 16, 2020 | Edge Computing, IoT, Open Source, Release

We are introducing the ObjectBox Generator today to simplify ObjectBox development for more programming languages, starting with C/C++. Additionally, we are releasing a brand new C++ API that goes hand in hand with the new generator. Historically, our C API was rather low level as it was focused on providing the foundation for our Swift and Go APIs. With this release we want to provide C/C++ developers with ObjectBox convenience and ease of use.

ObjectBox Generator takes over the burden of writing the binding code and data model declaration. Based on a single input file, it generates the code for you, so you can focus on the actual application logic.

Generator Example

ObjectBox let’s you handle data as FlatBuffers. For example, you can put and get data objects as FlatBuffers encoded bytes. To work with FlatBuffers, you need to define a FlatBuffer schema file (.fbs). And this file is also the input for ObjectBox Generator. This way, everything is defined in a single location.

Let’s say we have a FlatBuffers schema file “task.fbs” with the following content:

table Task {
    id: ulong;
    text: string;
    date_created: ulong;
    date_finished: ulong;
}

1

2

3

4

5

6

table Task {

id: ulong;

text: string;

date_created: ulong;

date_finished: ulong;

}

Now, we can tell ObjectBox Generator to use this file to generate C++ sources:

   ./objectbox-generator -cpp task.fbs

1	./objectbox-generator -cpp task.fbs

This makes ObjectBox Generator to generate the following files:

objectbox-model.h: source code to build the internal data model, that you need to pass when creating a store.
objectbox-model.json: keeps track of internal schema IDs; you don’t need to worry about this except that you should put it in your source control.
task-cpp.obx.h: the C++ value structs (data objects), binding code for FlatBuffers and the new Box class.

C++ API Example

Now, let’s use the previously generated code and the new C++ API around the Store and Box classes. A simple CRUD application boils down to a few lines:

#include "objectbox-cpp.h"
#include "objectbox-model.h"  // provides create_obx_model()
#include "task-cpp.obx.h"     // provides Task struct and bindings

int main(int argc, char* args[]) {
    obx::Store store(create_obx_model()); 
    obx::Box<Task> taskBox(store);

    obx_id id = box.put({.text = "Buy milk"});  // Create
    std::unique_ptr<Task> task = box.get(id);   // Read
    if (task) {    
        task->text += " & some bread";
        box.put(*task);                         // Update
        ...
        box.remove(id);                         // Delete
    }
    ...
}

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

#include "objectbox-cpp.h"

#include "objectbox-model.h" // provides create_obx_model()

#include "task-cpp.obx.h" // provides Task struct and bindings

int main(int argc, char* args[]) {

obx::Store store(create_obx_model());

obx::Box<Task> taskBox(store);

obx_id id = box.put({.text = "Buy milk"}); // Create

std::unique_ptr<Task> task = box.get(id); // Read

if (task) {

task->text += " & some bread";

box.put(*task); // Update

...

box.remove(id); // Delete

}

...

}

Note that the generated code is header-only and compatible with the existing ObjectBox C-API, allowing both to be used from the same application. The C and C++ APIs both have unique advantages: the C++ API uses RAII so you do not need to worry about cleaning up, while the C API has additional features, e.g. queries.

Open Source, Docs

ObjectBox Generator is open source and available on GitHub. The repository comes with a readme file that also serves as a documentation. Among other things, you will find ObjectBox specific annotations there, which are used in fbs files to express ObjectBox-specific concerns. For example, in the definition of Task above, we used ulong as a FlatBuffers type to store dates. However, FlatBuffers does not know what a date is and we use ObjectBox annotations to express this:

 /// objectbox: date
    date_created: ulong;

1 2	/// objectbox: date date_created: ulong;

For our initial release of ObjectBox Generator and the public C++ API we decided on labeling it as version 0.9. Although we are already very close to a 1.0 and we wanted to gather some feedback before our first major release. As we can still change the API or smooth out any rough edges you may find, we cannot stress enough how much we welcome and appreciate your feedback at this point. Thank you!

ObjectBox Go 1.1

by Ivan | Dec 16, 2019 | IoT, Release

The 1.1 release of ObjectBox for Go is now available, bringing new features such as Box insert() and update() semantics, a new AsyncBox with all write operations (put, insert, update, delete), improved Queries with order and aliases; as well as some fixes and quality of life improvements, such as time. Time support or more forgiving generator code validation. For the full list of changes see the changelog.

To upgrade to the latest version, run go get -u in your project and don’t forget to re-run the generator to make sure all the code is in sync and you get the new features:

go get -u github.com/objectbox/objectbox-go
go generate ./…

1 2	go get -u github.com/objectbox/objectbox-go go generate ./…

Async Box

The new AsyncBox gives you asynchronous processing for write operations such as Put, Insert, Update, Remove, RemoveId.

First a quick reminder how a standard (synchronous) Box works:

box := model.BoxForTask(ob)

// Create
id, _ := box.Put(&model.Task{
      Text: "Buy milk",
})

task, _ := box.Get(id) // Read
task.Text += " & some bread"
box.Put(task) // Update
box.Remove(task) // Delete

1

2

3

4

5

6

7

8

9

10

11

box := model.BoxForTask(ob)

// Create

id, _ := box.Put(&model.Task{

Text: "Buy milk",

})

task, _ := box.Get(id) // Read

task.Text += " & some bread"

box.Put(task) // Update

box.Remove(task) // Delete

Now, let’s have a look at the new AsyncBox. Let’s say tasks are processed in multiple iterations by calling a “WorkOn(*Task)”. Let’s also assume that WorkOn() sets a “finished” flag on the object if it was able to complete a task in an iteration. In that case, the task can be removed from the database. Otherwise, partial progress on the task should be saved for the next iteration.

asyncBox := box.Async()

    var tasks = QueryTasksToWorkOn()
    for _, task := range tasks {
        WorkOn(task) // Consumes some CPU time
        if task.finished {
            // Remove a finished task
            asyncBox.Remove(task)
        } else {
            // Save progress on task
            asyncBox.Update(task)
        }
    }

1

2

3

4

5

6

7

8

9

10

11

12

13

asyncBox := box.Async()

var tasks = QueryTasksToWorkOn()

for _, task := range tasks {

WorkOn(task) // Consumes some CPU time

if task.finished {

// Remove a finished task

asyncBox.Remove(task)

} else {

// Save progress on task

asyncBox.Update(task)

}

So, what’s the advantage of using AsyncBox in this example? Because we don’t wait for updating or removing a task, we just created an efficient pipeline: we can spend all computational resources on WorkOn(), while AsyncBox performs persistence in the background. Both steps never have to wait for each other.

The second advantage of AsyncBox is “transaction merging.” Because “WorkOn” takes some time, we operate on a single object at a time. A synchronous solution would require a transaction per object, introducing significant disk overhead. AsyncBox can reduce the amount of transactions required and thus dramatically improve throughput.

You may also have noted the usage of “Update()” instead of the standard “Put”. An update is different from a put as it only persists the object if it already exists in the database. Let’s say our example has another process that removes Tasks; a standard put operation might “resurrect” a task previously removed by the other process. If we don’t want that to happen, we can use update semantics. The new update and insert operations are also available in the standard Box API.

Please let us, and everyone else, know what you like about this release and ObjectBox in general. We’d love to hear from you to know what you’d like to see next.

Looking for an easy way to sync data between devices? Check out ObjectBox Sync, sign up for early access, and look out for the release early 2020!

Sign up for ObjectBox Sync