V1.3.4 – 2017/12/07

Improvements

ToOne now implements equals() and hashCode() based on the targetId property

Android ABI x86_64 was added to the aar

Fixes

ID verification does not complain about “resurrected” objects that were loaded, removed, and put again

Fixed setting Query parameters for Date type

Fixes for ObjectBox browser

V1.3.3 (1.3.x) – 2017/12/04

Please update to the latest version. We made important changes and fixes under the hood to make ObjectBox perform better, generally, and especially in concurrent scenarios. In addition, 1.3.x comes with several improvements for developers.

V0.9.14 (beta) 2017/08/14 Standalone relations, new build tools

New Features

No more in-place code generation: Java source code is all yours now. This is based on the new build tool chain introduced in 0.9.13. Thus Kotlin and Java share the same build system. The old Java-based plugin is still available (plugin ID “io.objectbox.legacy”) in this version.

ToOne and ToMany are now serializable (which does not imply serializing is a good idea)

ObjectBox may now opt to construct entities using the no-args constructor if the all-args constructor is absent

Prevents opening two BoxStores for the same DB file, which may have side effects that are hard to debug

Various minor and internal improvements and fixes

Fixes

Fixed ToOne without an explicit target ID property

Fixed type check of properties to allow ToMany (instead of List)

Fixed @Convert in combination with List

Fixed a race condition with cursor deletion when Java’s finalizer kicked in potentially resulting in a SIGSEGV

Fixed a leak with potentially occurring with indexes

V0.9.12 (beta) 2017/05/08 ToMany class

Update 2017/05/19: We just released 0.9.12.1 for the Gradle plugin (only), which fixes two problems with parsing of to-many relations.

Added the new list type ToMany which represents a to-many relation. A ToMany object will be automatically assigned to List types in the entity, eliminating a lot of generated code in the entity.

ToMany comes with change tracking: all changes (add/remove) are automatically applied to the DB when its hosting entity is persisted via put(). Thus, the list content is synced to the DB, e.g. their relationship status is updated and new entities are put.

Streamlined annotations (breaking API changes): @Generated(hash = 123) becomes @Generated(123), @Property was removed, @NameInDb replaces attributes in @Entity and the former @Property, Backlinking to-many relations require @Backlink (only), @Relation is now only used for to-one relations (and is subject to change in the next version)

V0.9.11 (beta) 2017/04/25: Various improvements

Smarter to-one relations: if you put a new object that also has a new to-one relation object, the latter will also be put automatically.

Getters and setters for properties are now only generated if no direct field access is possible

JSR-305 annotations (@Nullable and others) to help the IDE find problems in your code

@Uid(-1) will reassign IDs to simplify some migrations (docs will follow soon)

V0.9.8 (beta) 2017/02/22: Going Reactive

New features

Bug fixes

Fixed: Changing the order of an entity’s properties could cause errors in some cases

Fixed: Querying using relation IDs

V0.9.7 (beta) 2017/02/10

New features

LazyList returned by Query: another query option to defer getting actual objects until actually accessing them. This enables memory efficient iterations over large results. Also minimizes the time for a query to return. Note: LazyList cannot be combined with order specifications just yet.

QueryBuilder and Query now support Date and boolean types directly

QueryBuilder supports now a notIn opperator

put() now uses entity fields directly unless they are private (can be more efficient than calling getters)

Breaking internal changes

At this early point in the beta we decided to break backward compatibility. This allowed us to make important improvements without worrying about rather complex migrations of previous versions. We believe this was a special situation and future versions will likely be backward compatible although we cannot make promises. If you intend to publish an app with ObjectBox it’s a good idea to contact us before.

The internal data format was optimized to store data more compact. Previous database files are not compatible and should be deleted.

We improved some details how IDs are used in the meta model. This affects the model file, which is stored in your project directory (objectbox-models/default.json). Files created by previous versions should be deleted.