Skip to main content

Object Mapping In Aerospike

Aerospike supports two different mechanisms for mapping your Plain Old Java Objects (POJOs) onto Aerospike records. These are:

  • Spring Data
  • Java Object Mapper

Both Spring Data Aerospike and Java Object Mapper support reactive APIs (async, non-blocking operations) as well as synchronous implementations. Both projects are fully open source with good community involvement and Aerospike Engineering support.

Spring Data​

Spring Data Aerospike provides out of the box CRUD operations and basic queries with zero implementation required using an AerospikeRepository interface, as well as the flexibility of more complicated or specific operations and queries using the AerospikeTemplate class. People who have used Spring Data with other database technologies will find the annotation driven configuration very familiar. People new to Spring Data will find the ease of implementation of query methods very refreshing.

Spring Data Aerospike uses Spring Boot's familiar approach for configuration, services and repositories. All the components are beans initialized automatically when you extend Spring Data Aerospike's configuration class, and you can use these beans in a Spring-like manner.

Spring Data Aerospike also supports Spring Cache which is a cache-specific API. A blog post describing the interaction between Spring Data and Spring Cache can be found here.

More information and numerous examples can be found here.

Java Object Mapper​

The Java Object Mapper is a standalone library on top of the Aerospike Java Client that provides conversion capabilities between the Aerospike database and POJOs. This mapping is driven by annotations similar to those used in Spring Data, but it does not rely on the Spring Framework at all and hence can be used in non-Spring projects. Additionally, as it is custom written for Aerospike, it can harness some power of Aerospike which Spring Data Aerospike cannot as it needs to conform to the framework specification.

For example, consider a parent-child relationship such as a Customer with an Account. Spring Data always stores the Account details in a Map inside the Customer record. This works well if the Account is a aggregated entity and has no need to exist outside of the context of a Customer, but for associated entities which do need to exist outside of the parent entity, this can be a problem. The Java Object Mapper allows you to choose whether child objects are embedded in the parent object or are references stored in the parent object, and how to store children objects inside the parent. For example, you can decide whether a child object should be stored in a Map or in a List.

The Java Object Mapper handles seamless conversions of POJOs too and from database representations but queries must be manually coded, whereas the Spring Data Aerospike impelemtnation gives very easy mechanisms to define queries.

Additional Resources​