Note	Copies of this document may be made for your own use and for distribution to others, provided that you do not charge any fee for such copies and further provided that each copy contains this Copyright Notice, whether distributed in print or electronically.

Preface

The Spring Data Aerospike project applies core Spring concepts and provides interface for using Aerospike key-value style data store. We provide a "repository" and a "template" as high-level abstractions for storing and querying data. You will notice similarities to the JDBC support in the Spring Framework.

This chapter provides some basic introduction to Spring and Aerospike, it explains Aerospike concepts and syntax. The rest of the documentation refers to Spring Data Aerospike features and assumes the user is familiar with Aerospike as well as Spring concepts.

Knowing Spring

Spring Data uses Spring framework’s core functionality, such as the IoC container, type conversion system, DAO exception hierarchy etc. While it is not important to know the Spring APIs, understanding the concepts behind them is. At a minimum, the idea behind IoC should be familiar regardless of IoC container you choose to use.

To learn more about Spring, you can refer to the comprehensive documentation that explains in detail the Spring Framework. There are a lot of articles, blog entries and books on the matter - take a look at the Spring framework documentation reference for more information.

Knowing NoSQL and Aerospike

NoSQL stores have taken the storage world by storm. It is a vast domain with a plethora of solutions, terms and patterns (to make things worthwhile even the term itself has multiple meanings). While some principles are common, it is crucial that the user is familiar to some degree with Aerospike key-value store operations that supply the mechanism for associating keys with a set of named values, similar to a row in standard RDBMS terminology. The data layer in Aerospike Database is optimized to store data in solid state drives, RAM, or traditional rotational media. The database indices are stored in RAM for quick availability, and data writes are optimized through large block writes to reduce latency. The software also employs two sub-programs that are codenamed Defragmenter and Evictor. Defragmenter removes data blocks that have been deleted, and Evictor frees RAM space by removing references to expired records.

The jumping off ground for learning about Aerospike is www.aerospike.com. Here is a list of other useful resources:

The technical documentation introduces Aerospike and contains links to getting started guides, reference documentation and tutorials.
The java client documentation provides a convenient way to interact with an Aerospike instance in combination with the online Getting started
Aerospike Community

Requirements

Spring Data Aerospike binaries require JDK level 17.0 and above.

In terms of server, it is required to use at least Aerospike server version 6.1 (recommended to use the latest version when possible).

Additional Help Resources

Learning a new framework is not always straightforward. In this section, we try to provide what we think is an easy-to-follow guide for starting with Spring Data Aerospike module. However, if you encounter issues, or you are just looking for advice, feel free to use one of the links below:

Support

There are a few support options available:

Questions & Answers

Developers post questions and answers on Stack Overflow. The two key tags to search for related answers to this project are:

Following Development

If you encounter a bug or want to suggest an improvement, please create an issue on GitHub.

Reference documentation

Functionality

Spring Data Aerospike project aims to provide a familiar and consistent Spring-based programming model providing integration with the Aerospike database.

Spring Data Aerospike supports a wide range of features summarized below:

Supporting Repository interfaces (out-of-the-box CRUD operations and query implementations, for more information see Aerospike Repositories)
AerospikeTemplate for lower-level access to common Aerospike operations and fine-tuning (for more information see AerospikeTemplate)
Feature Rich Object Mapping integrated with Spring’s Conversion Service
Translating exceptions into Spring’s Data Access Exception hierarchy
Annotation-based metadata mapping
Ability to directly utilize Aerospike Java client functionality

Installation & Usage

Getting Started

First, you need a running Aerospike server to connect to.

To use Spring Data Aerospike you can either set up Spring Boot or Spring application. Basic setup of Spring Boot application is described here: https://projects.spring.io/spring-boot.

In case you do not want to use Spring Boot, the best way to manage Spring dependencies is to declare spring-framework-bom of the needed version in the dependencyManagement section of your pom.xml:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-framework-bom</artifactId>
            <version>${spring-data-aerospike.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Note	To create a Spring project in STS (Spring Tool Suite) go to File → New → Spring Template Project → Simple Spring Utility Project → press "Yes" when prompted. Then enter a project and a package name such as `org.spring.aerospike.example`.

Adding Dependency

The first step is to add Spring Data Aerospike to your build process. It is recommended to use the latest version which can be found on the GitHub Releases page.

Adding Spring Data Aerospike dependency in Maven:

<dependency>
    <groupId>com.aerospike</groupId>
    <artifactId>spring-data-aerospike</artifactId>
    <version>${spring-data-aerospike.version}</version>
</dependency>

Adding Spring Data Aerospike dependency in Gradle:

implementation group: 'com.aerospike', name: 'spring-data-aerospike', version: '${spring-data-aerospike.version}'

Connecting to Aerospike DB

There are two ways of configuring a basic connection to Aerospike DB.

Overriding getHosts() and nameSpace() methods of the AbstractAerospikeDataConfiguration class:

@Configuration
@EnableAerospikeRepositories(basePackageClasses = { PersonRepository.class})
public class AerospikeConfiguration extends AbstractAerospikeDataConfiguration {
    @Override
    protected Collection<Host> getHosts() {
        return Collections.singleton(new Host("localhost", 3000));
    }
    @Override
    protected String nameSpace() {
        return "test";
    }
}

Using application.properties:

Basic configuration in this case requires enabling repositories and then setting hosts and namespace in the application.properties file.

@Configuration
@EnableAerospikeRepositories(basePackageClasses = { PersonRepository.class})
public class AerospikeConfiguration extends AbstractAerospikeDataConfiguration {

}

In application.properties:

# application.properties
spring-data-aerospike.hosts=localhost:3000
spring-data-aerospike.namespace=test

Note	Return values of `getHosts()` and `nameSpace()` methods of the `AbstractAerospikeDataConfiguration` class have precedence over `hosts` and `namespace` parameters set via application.properties.

For more detailed information see Configuration.

Creating Functionality

The base functionality is provided by AerospikeRepository interface.

It typically takes 2 parameters:

The type managed by a class (it is typically entity class) to be stored in the database.
The type of ID.

Application code typically extends this interface for each of the types to be managed, and methods can be added to the interface to determine how the application can access the data. For example, consider a class Person with a simple structure:

@AllArgsConstructor
@NoArgsConstructor
@Data
@Document
public class Person {
    @Id
    private long id;
    private String firstName;
    private String lastName;
    @Field("dob")
    private Date dateOfBirth;
}

Note that this example uses the Project Lombok annotations to remove the need for explicit constructors and getters and setters. Normal POJOs which define these on their own can ignore the @AllArgsConstructor, @NoArgsConstructor and @Data annotations. The @Document annotation tells Spring Data Aerospike that this is a domain object to be persisted in the database, and @Id identifies the primary key of this class. The @Field annotation is used to create a shorter name for the bin in the Aerospike database (dateOfBirth will be stored in a bin called dob in this example).

For the Person object to be persisted to Aerospike, you must create an interface with the desired methods for retrieving data. For example:

public interface PersonRepository extends AerospikeRepository<Person, Long> {
    List<Person> findByLastName(String lastName);
}

This defines a repository that can write Person entities and also query them by last name. The AerospikeRepository extends both PagingAndSortingRepository and CrudRepository, so methods like count(), findById(), save() and delete() are there by default. Those who need reactive flow can use ReactiveAerospikeRepository instead.

Note

Repository is just an interface and not an actual class. In the background, when your context gets initialized, actual implementations for your repository descriptions get created, and you can access them through regular beans. This means you will omit lots of boilerplate code while still exposing full CRUD semantics to your service layer and application.

Example repository is ready for use. A sample Spring Controller which uses this repository could be the following:

@RestController
public class ApplicationController {
    @Autowired
    private PersonRepository personRepsitory;

    @GetMapping("/seed")
    public int seedData() {
        Person person = new Person(1, "Bob", "Jones", new GregorianCalendar(1971, 12, 19).getTime());
        personRepsitory.save(person);
        return 1;
    }

    @GetMapping("/findByLastName/{lastName}")
    public List<Person> findByLastName(@PathVariable(name = "lastName", required=true) String lastName) {
        return personRepsitory.findByLastName(lastName);
    }
}

Invoking the seed method above gives you a record in the Aerospike database which looks like:

aql> select * from test.Person where pk = "1"
+-----+-----------+----------+-------------+-------------------------------------+
| PK  | firstName | lastName | dob         | @_class                             |
+-----+-----------+----------+-------------+-------------------------------------+
| "1" | "Bob"     | "Jones"  | 64652400000 | "com.aerospike.sample.model.Person" |
+-----+-----------+----------+-------------+-------------------------------------+
1 row in set (0.001 secs)

Note	The fully qualified path of the class is listed in each record. This is needed to instantiate the class correctly, especially in cases when the compile-time type and runtime type of the object differ. For example, where a field is declared as a super class but the instantiated class is a subclass.

Note

By default, the type of the field annotated with @id is turned into a String to be stored in Aerospike database. If the original type cannot be persisted (see keepOriginalKeyTypes for details), it must be convertible to String and will be stored in the database as such, then converted back to the original type when the object is read. This is transparent to the application but needs to be considered if using external tools like AQL to view the data.

Aerospike repositories

Introduction

One of the main goals of the Spring Data is to significantly reduce the amount of boilerplate code required to implement data access layers for various persistence stores.

One of the core interfaces of Spring Data is Repository. This interface acts primarily to capture the types to work with and to help user to discover interfaces that extend Repository.

In other words, it allows user to have basic and complicated queries without writing the implementation. This builds on the Core Spring Data Repository Support, so make sure you’ve got a sound understanding of this concept.

Usage

To access entities stored in Aerospike you can leverage repository support that eases implementing those quite significantly. To do so, simply create an interface for your repository:

Example 1. Sample Person entity

public class Person {

	@Id
	private String id;
	private String name;
	private int age;
	public Person(String id, String name, int age) {
		this.id = id;
		this.name = name;
		this.age = age;
	}
  // … getters and setters omitted
}

We have a quite simple domain object here. The default serialization mechanism used in AerospikeTemplate (which is backing the repository support) regards properties named "id" as document id. Currently we support String and long as id-types.

Example 2. Basic repository interface to persist Person entities

public interface PersonRepository extends AerospikeRepository<Person, String> {

	List<Person> findByName(String name);

	List<Person> findByNameStartsWith(String prefix);

}

Right now this interface simply serves typing purposes, but we will add additional methods to it later. In your Spring configuration simply add

Example 3. General Aerospike repository Spring configuration

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:aerospike="http://www.springframework.org/schema/data/aerospike"
  xsi:schemaLocation="http://www.springframework.org/schema/beans
    https://www.springframework.org/schema/beans/spring-beans-3.0.xsd
    http://www.springframework.org/schema/data/aerospike
    https://www.springframework.org/schema/data/aerospike/spring-aerospike-1.0.xsd">

  <aerospike:aerospike id="aerospike" />

  <bean id="aerospikeTemplate" class="rg.springframework.data.aerospike.core.AerospikeTemplate">
 </bean>

  <aerospike:repositories base-package="org.springframework.data.aerospike.example.data" />

</beans>

This namespace element will cause the base packages to be scanned for interfaces extending AerospikeRepository and create Spring beans for each of them found. By default, the repositories will get an AerospikeTemplate Spring bean wired that is called aerospikeTemplate.

If you’d rather like to go with JavaConfig use the @EnableAerospikeRepositories annotation. The annotation carries the very same attributes like the namespace element. If no base package is configured the infrastructure will scan the package of the annotated configuration class.

Example 4. JavaConfig for repositories

@Configuration
@EnableAerospikeRepositories(basePackages = "org.springframework.data.aerospike.example")
public class TestRepositoryConfig {
	public @Bean(destroyMethod = "close") AerospikeClient aerospikeClient() {

		ClientPolicy policy = new ClientPolicy();
		policy.failIfNotConnected = true;

		return new AerospikeClient(policy, "52.23.205.208", 3000);
	}

	public @Bean AerospikeTemplate aerospikeTemplate() {
		return new AerospikeTemplate(aerospikeClient(), "test");
	}
}

As our domain repository extends PagingAndSortingRepository it provides you with CRUD operations as well as methods for paginated and sorted access to the entities. Working with the repository instance is just a matter of dependency injecting it into a client. So accessing the second page of `Person`s at a page size of 10 would simply look something like this:

Example 5. Paging access to Person entities

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class PersonRepositoryTests {

    @Autowired PersonRepository repository;

    @Test
    public void readsFirstPageCorrectly() {

      Page<Person> persons = repository.findAll(new PageRequest(0, 10));
      assertThat(persons.isFirstPage(), is(true));
    }
}

The sample creates an application context with Spring’s unit test support which will perform annotation-based dependency injection into test cases. Inside the test method, we simply use the repository to query the datastore. We hand the repository a PageRequest instance that requests the first page of persons at a page size of 10.

Query methods

Most of the data access operations you usually trigger on a repository result in a query being executed against the Aerospike databases. Defining such a query is just a matter of declaring a method on the repository interface

Example 6. PersonRepository with query methods

public interface PersonRepository extends PagingAndSortingRepository<Person, String> {

    List<Person> findByName(String name);                              (1)

    Page<Person> findByName(String name, Pageable pageable);           (2)

    List<Person> findByNameStartsWith(String prefix);                  (3)

 }

The method shows a query for all people with the given name. The query will be derived by parsing the method name for constraints that can be concatenated with And and Or.
Applies pagination to a query. Just equip your method signature with a Pageable parameter and let the method return a Page instance, and it will automatically page the query accordingly (i.e. return the required part of results).
Uses query-based partial name search.

Here’s a delete insert and query example

@ContextConfiguration(classes = TestRepositoryConfig.class)
public class RepositoryExample {

	@Autowired
	protected PersonRepository repository;
	@Autowired
	AerospikeOperations aerospikeOperations;
	@Autowired
	AerospikeClient client;

	public RepositoryExample(ApplicationContext ctx) {
		aerospikeOperations = ctx.getBean(AerospikeTemplate.class);
		repository = (PersonRepository) ctx.getBean("personRepository");
		client = ctx.getBean(AerospikeClient.class);
	}

	protected void setUp() {
		repository.deleteAll();
		Person dave = new Person("Dave-01", "Matthews", 42);
		Person donny = new Person("Dave-02", "Macintire", 39);
		Person oliver = new Person("Oliver-01", "Matthews", 4);
		Person carter = new Person("Carter-01", "Beauford", 49);
		Person boyd = new Person("Boyd-01", "Tinsley", 45);
		Person stefan = new Person("Stefan-01", "Lessard", 34);
		Person leroi = new Person("Leroi-01", "Moore", 41);
		Person leroi2 = new Person("Leroi-02", "Moore", 25);
		Person alicia = new Person("Alicia-01", "Keys", 30);
		repository.createIndex(Person.class, "person_name_index", "name",
				IndexType.STRING);
		List<Person> all = (List<Person>) repository.save(Arrays.asList(oliver,
				dave, donny, carter, boyd, stefan, leroi, leroi2, alicia));
	}

	protected void cleanUp() {
		repository.deleteAll();
	}

	protected void executeRepositoryCall() {
		List<Person> result = repository.findByName("Beauford");
		System.out.println("Results for exact match of 'Beauford'");
		for (Person person : result) {
			System.out.println(person.toString());
		}
		System.out.println("Results for name starting with letter 'M'");
		List<Person> resultPartial = repository.findByNameStartsWith("M");
		for (Person person : resultPartial) {
			System.out.println(person.toString());
		}
	}

	public static void main(String[] args) {
		ApplicationContext ctx = new AnnotationConfigApplicationContext(
				TestRepositoryConfig.class);
		RepositoryExample repositoryExample = new RepositoryExample(ctx);
		repositoryExample.setUp();
		repositoryExample.executeRepositoryCall();
		repositoryExample.cleanUp();
	}
}

Reactive Aerospike repositories

Introduction

This chapter will point out the specialties for reactive repository support for Aerospike. This builds on the core repository support explained in repositories. So make sure you’ve got a sound understanding of the basic concepts explained there.

Reactive Composition Libraries

The reactive space offers various reactive composition libraries. The most common library is Project Reactor.

Spring Data Aerospike is built on top of the Aerospike Reactor Java Client Library, to provide maximal interoperability by relying on the Reactive Streams initiative. Static APIs, such as ReactiveAerospikeOperations, are provided by using Project Reactor’s Flux and Mono types. Project Reactor offers various adapters to convert reactive wrapper types (Flux to Observable and vice versa).

Spring Data’s Repository abstraction is a dynamic API, mostly defined by you and your requirements as you declare query methods. Reactive Aerospike repositories can be implemented by using Project Reactor wrapper types by extending from the following library-specific repository interface:

ReactiveAerospikeRepository

Usage

To access domain entities stored in an Aerospike you can use our sophisticated repository support that eases implementing those quite significantly. To do so, create an interface similar to your repository. Before you can do that, though, you need an entity, such as the entity defined in the following example:

Example 7. Sample Person entity

public class Person {

  @Id
  private String id;
  private String firstname;
  private String lastname;
  private Address address;

  // … getters and setters omitted
}

We have a quite simple domain object here. The default serialization mechanism used in ReactiveAerospikeTemplate (which is backing the repository support) regards properties named id as document ID. Currently, we support String and long as id-types. The following example shows how to create an interface that defines queries against the Person object from the preceding example:

Example 8. Basic repository interface to persist Person entities

public interface ReactivePersonRepository extends ReactiveAerospikeRepository<Person, String> {

  Flux<Person> findByFirstname(String firstname);

}

Right now this interface simply serves typing purposes but we will add additional methods to it later.

For Java configuration, use the @EnableReactiveAerospikeRepositories annotation. The annotation carries the base packages attribute. These base packages are to be scanned for interfaces extending ReactiveAerospikeRepository and create Spring beans for each of them found. If no base package is configured, the infrastructure scans the package of the annotated configuration class.

The following listing shows how to use Java configuration for a repository:

Example 9. Java configuration for repositories

@Configuration
@EnableReactiveAerospikeRepositories(basePackages = "org.springframework.data.aerospike.example")
public class TestRepositoryConfig extends AbstractReactiveAerospikeDataConfiguration {
    @Override
    protected Collection<Host> getHosts() {
        return Collections.singleton(new Host("52.23.205.208", 3000));
    }

    @Override
    protected String nameSpace() {
        return "test";
    }

    @Override
    protected EventLoops eventLoops() {
        return new NioEventLoops();
    }
}

As our domain repository extends ReactiveAerospikeRepository it provides you with CRUD operations. Working with the repository instance is a matter of dependency injecting it into a client, as the following example shows:

Example 10. Access to Person entities

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration
public class PersonRepositoryTests {
    @Autowired
    ReactivePersonRepository repository;

    @Test
    public void findByFirstnameCorrectly() {
      Flux<Person> persons = repository.findByFirstname("TestFirstName");
    }
}

Query methods

Example 11. PersonRepository with query methods

public interface ReactivePersonRepository extends ReactiveAerospikeRepository<Person, String> {

  Flux<Person> findByFirstname(String firstname);                                   (1)

  Flux<Person> findByFirstname(Publisher<String> firstname);                        (2)

  Mono<Person> findByFirstnameAndLastname(String firstname, String lastname);       (3)

  Mono<Person> findFirstByLastname(String lastname);                                (4)

  Flux<Person> findByFirstnameStartsWith(String prefix);                            (5)

}

The method shows a query for all people with the given firstname. The query is derived by parsing the method name for constraints that can be concatenated with And and Or. Thus, the method name results in a query expression of {"firstname" : firstname}.
The method shows a query for all people with the given firstname once the firstname is emitted by the given Publisher.
Find a single entity for the given criteria. It completes with IncorrectResultSizeDataAccessException on non-unique results.
Unless <3>, the first entity is always emitted even if the query yields more result documents.
The method shows a query for all people with the firstname starts from prefix

Examples

Here’s a delete, insert and query example

@ContextConfiguration(classes = TestRepositoryConfig.class)
public class ReactiveRepositoryExample {

    @Autowired
    protected ReactivePersonRepository repository;
    @Autowired
    ReactiveAerospikeOperations aerospikeOperations;
    @Autowired
    IAerospikeReactorClient client;

    public RepositoryExample(ApplicationContext ctx) {
        aerospikeOperations = ctx.getBean(ReactiveAerospikeTemplate.class);
        repository = (ReactivePersonRepository) ctx.getBean("reactivePersonRepository");
        client = ctx.getBean(IAerospikeReactorClient.class);
    }

    protected void setUp() {
        // Insert new Person items into repository
        Person dave = new Person("Dave-01", "Matthews", 42);
        Person donny = new Person("Dave-02", "Macintire", 39);
        Person oliver = new Person("Oliver-01", "Matthews", 4);
        Person carter = new Person("Carter-01", "Beauford", 49);
        List<Person> all = saveAll(Arrays.asList(dave, donny, oliver, carter))
            .collectList().block();
    }

    protected void cleanUp() {
        // Delete all Person items from repository
        repository.findAll().flatMap(a -> repository.delete(a)).blockLast();
    }

    protected void executeRepositoryCall() {
        System.out.println("Results for first name exact match of 'Dave-02'");
        repository.findByFirstname("Dave-02")
            .doOnNext(person -> System.out.println(person.toString())).blockLast();

        System.out.println("Results for first name starting with letter 'D'");
        repository.findByFirstnameStartsWith("D")
            .doOnNext(person -> System.out.println(person.toString())).blockLast();
    }

    public static void main(String[] args) {
        ApplicationContext ctx =
            new AnnotationConfigApplicationContext(TestRepositoryConfig.class);
        ReactiveRepositoryExample repositoryExample = new ReactiveRepositoryExample(ctx);
        repositoryExample.setUp();
        repositoryExample.executeRepositoryCall();
        repositoryExample.cleanUp();
    }
}

Restrictions

ReactiveAerospikeRepository currently does not support the next operations:

all operations with indexes (create, delete, exists)
count()
deleteAll()

This limitation is due to the lack of corresponding asynchronous methods in the Aerospike client.

Projections with Aerospike

Spring Data Aerospike supports Projections, a mechanism that allows you to fetch only relevant fields from Aerospike for a particular use case. This results in better performance, less network traffic, and a better understanding of what is required for the rest of the flow.

For more details, refer to Spring Data documentation: Projections.

For example, consider a Person class:

@AllArgsConstructor
@NoArgsConstructor
@Data
@Document
public class Person {
    public enum Gender {
        MALE, FEMALE;
    }
    @Id
    private long id;
    private String firstName;
    @Indexed(name = "lastName_idx", type = IndexType.STRING)
    private String lastName;
    @Field("dob")
    private Date dateOfBirth;
    private long heightInCm;
    private boolean enabled;
    private Gender gender;
    private String hairColor;
    private String eyeColor;
    private String passportNo;
    private String passptCnty;
}

This is a moderately complex object, and a production object is likely to be more complex. The use case might call for a search box that shows the firstName, lastName and dateOfBirth fields, allowing the user to select a Person based on the criteria upon which the full object will be shown.

A simple projection of this object might be:

@Data
@Builder
public class SearchPerson {
    private String firstName;
    private String lastName;
    @Field("dob")
    private Date dateOfBirth;
}

To tell Spring Data how to create a SearchPerson it is necessary to create a method on the Person class:

public SearchPerson toSearchPerson() {
    return SearchPerson.builder()
            .firstName(this.getFirstName())
            .lastName(this.getLastName())
            .dateOfBirth(this.getDateOfBirth())
            .build();
}

Now the repository interface can be extended to return this projection:

public interface PersonRepository extends AerospikeRepository<Person, Long> {
    public List<Person> findByLastName(String lastName);
    public List<SearchPerson> findSearchPersonByLastName(String lastName);
}

Notice that the method name now dictates the return type of SearchPerson as well as changing the return value. When this method is executed, Aerospike loads the full Person objects out of storage, invokes the toSearchPerson on each person and returns the resulting SearchPerson instances. This reduces the required network bandwidth to present these objects to the front end and simplifies logic.

A blog post with more details on projections can be found here.

Query Methods

Spring Data Aerospike supports defining queries by method name in the Repository interface so that the implementation is generated. The format of method names is fairly flexible, comprising a verb and criteria.

Some of the verbs include find, query, read, get, count and delete. For example, findByFirstName, countByLastName etc.

For more details, refer to basic Spring Data documentation: Defining Query Methods.

Repository Query Keywords

Here are the references to the examples of repository queries:

Note

Id repository read queries (like findById(), findByIds(), findByFirstNameAndId(), findAllById(), countById(), existsById() etc.) utilize get() operation of the underlying Java client. Repository read queries without id (like findByFirstName(), findByFirstNameAndLastName(), findAll() etc.) utilize query() operation of the underlying Java client.

Repository Interface Example

Below is an example of an interface with several query methods:

public interface PersonRepository extends AerospikeRepository<Person, Long> {
    List<Person> findByLastName(String lastName);
    List<Person> findByLastNameContaining(String lastName);
    List<Person> findByLastNameStartingWith(String lastName);
    List<Person> findByLastNameAndFirstNameContaining(String lastName, String firstName);
    List<Person> findByAgeBetween(long startAge, long endAge);
    Optional<Person> findById(Long id);
}

Simple Property Repository Queries

Note	Repository read queries without id utilize `query()` operation of the underlying Java client.

Keyword Repository query sample Snippet Notes

Keyword	Repository query sample	Snippet	Notes
Is, Equals or no keyword	`findByLastName(String lastName)`	…where x.lastName = ?
Not, IsNot	`findByLastNameNot(String lastName)`	…where x.lastName <> ?
True, isTrue	`findByEnabledTrue()`	…where x.enabled = true
False, isFalse	`findByEnabledFalse()`	…where x.enabled = false
In, IsIn	`findByLastNameIn(Collection<String>)`	…where x.lastName in ?
NotIn, IsNotIn	`findByLastNameNotIn(Collection<String>)`	…where x.lastName not in ?
Null, IsNull	`findByEmailAddressIsNull()`	…where x.emailAddress = null or x.emailAddress does not exist	The same as "does not exist", objects and fields exist in AerospikeDB when their value is not equal to null.
Exists NotNull, IsNotNull	`findByEmailAddressExists()` `findByEmailAddressNotNull()`	…where x.emailAddress != null	"Exists" and "IsNotNull" represent the same functionality and can be used interchangeably, objects and fields exist in AerospikeDB when their value is not equal to null.
LessThan, IsLessThan	`findByAgeLessThan(int age) findByFirstNameLessThan(String string)`	…where x.age < ? …where x.firstName < ?	Strings are compared by order of each byte, assuming they have UTF-8 encoding. See information about ordering.
LessThanEqual, IsLessThanEqual	`findByAgeLessThanEqual(int age) findByFirstNameLessThanEqual(String string)`	…where x.age < = ? …where x.firstName < = ?	Strings are compared by order of each byte, assuming they have UTF-8 encoding. See information about ordering.
GreaterThan, IsGreaterThan	`findByAgeGreaterThan(int age) findByFirstNameGreaterThan(String string)`	…where x.age > ? …where x.firstName > ?	Strings are compared by order of each byte, assuming they have UTF-8 encoding. See information about ordering.
GreaterThanEqual, IsGreaterThanEqual	`findByAgeGreaterThanEqual(int age findByFirstNameGreaterThanEqual(String string)`	…where x.age >= ? …where x.firstName >= ?	Strings are compared by order of each byte, assuming they have UTF-8 encoding. See information about ordering.
Between, IsBetween	`findByAgeBetween(int lowerLimit, int upperLimit) findByFirstNameBetween(String lowerLimit, String upperLimit)`	…where x.age between ? and ? …where x.firstName between ? and ?	Strings are compared by order of each byte, assuming they have UTF-8 encoding. See information about ordering.
Before, IsBefore	`findByDateOfBirthBefore(Date date)`	…where x.dateOfBirth < ?
After, IsAfter	`findByDateOfBirthAfter(Date date)`	…where x.dateOfBirth > ?
StartingWith, IsStartingWith, StartsWith	`findByLastNameStartingWith(String string)`	…where x.lastName like 'abc%'
EndingWith, IsEndingWith, EndsWith	`findByLastNameEndingWith(String string)`	…where x.lastName like '%abc'
Like, IsLike, MatchesRegex	`findByLastNameLike(String lastNameRegex)`	…where x.lastName like ?
Containing, IsContaining, Contains	`findByLastNameContaining(String substring)`	…where x.lastName like '%abc%'
NotContaining, IsNotContaining, NotContains	`findByLastNameNotContaining(String substring)`	…where x.lastName not like '%abc%'
And	`findByLastNameAndFirstName(String lastName, String firstName)`	…where x.lastName = ? and x.firstName = ?
Or	`findByLastNameOrFirstName(String lastName, String firstName)`	…where x.lastName = ? or x.firstName = ?

Is, Equals

or no keyword

findByLastName(String lastName)

…where x.lastName = ?

Not, IsNot

findByLastNameNot(String lastName)

…where x.lastName <> ?

True, isTrue

findByEnabledTrue()

…where x.enabled = true

False, isFalse

findByEnabledFalse()

…where x.enabled = false

In, IsIn

findByLastNameIn(Collection<String>)

…where x.lastName in ?

NotIn, IsNotIn

findByLastNameNotIn(Collection<String>)

…where x.lastName not in ?

Null, IsNull

findByEmailAddressIsNull()

…where x.emailAddress = null or x.emailAddress does not exist

The same as "does not exist", objects and fields exist in AerospikeDB when their value is not equal to null.

Exists

NotNull, IsNotNull

findByEmailAddressExists()

findByEmailAddressNotNull()

…where x.emailAddress != null

"Exists" and "IsNotNull" represent the same functionality and can be used interchangeably, objects and fields exist in AerospikeDB when their value is not equal to null.

LessThan, IsLessThan

findByAgeLessThan(int age)

findByFirstNameLessThan(String string)

…where x.age < ?

…where x.firstName < ?