Aerospike + Spring: Why does PK type always change to varchar?

Question

Entity (very simple, for the test):

@Document(collection = "user_repo")
public class User {

    @Id
    private int id;
    private String name;
    private int age;
}

Repository

public interface AerospikeUserReactiveRepository extends ReactiveAerospikeRepository<User, Integer> {
}

Requested data from the database:

aql> select * from test
+-------------+----------------------------------------+------------------+-----------+
| PK          | name                                   | @_class          | age       |
+-------------+----------------------------------------+------------------+-----------+
| "761637962" | "21b50081-c244-4e98-9e5d-7b346f549154" | "com.model.User" | 761637962 |
| "626513063" | "7a171a11-b275-488b-ac29-e92b3f6f8668" | "com.model.User" | 626513063 |
| "422312771" | "c51ea6c5-840b-40eb-8616-e3447b363097" | "com.model.User" | 422312771 |
+-------------+----------------------------------------+------------------+-----------+
3 rows in set (0.053 secs)

Answer 1

Update:

Starting at Spring Data Aerospike 4.6.0 there is a new flag called "keepOriginalKeyTypes" in AerospikeDataSettings which defines how @Id fields (primary keys) and Map keys are stored, false is the default (which means store as String) to support backward compatibility. You can change it to true in order to store the original key type for PK and Map Keys (4.6.0 release notes: github.com/aerospike/spring-data-aerospike/releases/tag/4.6.0).

Previous Answer:

You are right,

In Spring Data Aerospike the PK is stored as a String, initially it was done because:

1. It has an advantage of being able to have any type of key/change the key on application layer without changing persistence layer.

2. It gives readable format in Aerospike when you need to see data directly in storage.

3. Spring Data Aerospike supports Composite Keys so for saving them as a readable string the most simple approach is using to string conversion.

Currently you can change it by using Custom Converters.

We do consider to support storing primitive types as it is out-of-the-box, it's in our backlog.