[BUG] New version of jnosq-arango is not backward compatible

[m4ttek]

Which JNoSQL project the issue refers to?

JNoSQL Databases

Bug description

As far as I investigated it, the problem is related to changing serialization from Jackson to JsonB with latest version.

Even if I tried to overwrite this new default by using builder.serde(JacksonSerde.create(objectMapper)); the behaviour completely changed and I get errors everywhere.

I don't understand why this changed was applied as a patch version. What should I do now as I'd rather to keep jackson which is used also with JAXRS in my projects.

JNoSQL Version

1.1.4

Steps To Reproduce

Just try to use jnosql-arangodb on existing project

Expected Results

There should be some layer of compatibility applied.

Code example, screenshot, or link to a repository

No response

[rashtao]

Hi @m4ttek ,

the change is from eclipse-jnosql/jnosql-databases#292.
This was supposed to affect the internal behavior only, i.e. serializing and deserializing to/from CommunicationEntity.

Can you provide code example to reproduce your exceptions?

[otaviojava]

I need to do further tests, but I do believe that impact was changing to JsonObjectonce it is an interface instead of a defined type as we had on BaseDocument. It might impact the serialization.

I will create a test scenario this evening.

[m4ttek]

Hi @rashtao,

I've been always using additional @Column for _key as it was required for proper handling of updates in collections, i.e.:

@AggregateRoot
@Builder
@Entity(COLLECTION_NAME)
@Data
@NoArgsConstructor
@AllArgsConstructor
public class AppraisementPeriod {

    public static final String COLLECTION_NAME = "appraisement_periods";

    @InternalId
    @Id
    private String id;

    @InternalKey
    @Column("_key")
    private String key;

    @Column
    @NotBlank
    private String name;

    @Column
    @NotNull
    private LocalDate startDate;

    @Column
    @NotNull
    private LocalDate endDate;
}

Apart from that, I additionally configured Jackson for handling nested objects and values:

    private void programmaticallyConfigureArangoSerde(ArangoDB arangoDB) {
        if (arangoDB.getSerde().getUserSerde() instanceof JacksonSerde jacksonSerde) {
            // it doesn't change the behaviour of JNosql as it's using its own seralization system
            jacksonSerde.configure(objectMapper -> {
                objectMapper.findAndRegisterModules();
                objectMapper.configure(DeserializationFeature.FAIL_ON_IGNORED_PROPERTIES, true)
                        .configure(SerializationFeature.FAIL_ON_EMPTY_BEANS, false)
                        .configure(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS, false);
            });
        }
    }

But this shouldn't have such impact on everything.

Maybe it'd be better to allow to choose your own serialization system per project? Jackson should be able to handle any java type (apart from polimorfism which require additional annotation based hints).

What's more, I'm usign Spark Arango Datasource in my project which internally uses Jackson, not JsonB - if there are any differences in serde handling I'll probably have even more bugs ;)

[otaviojava]

I need to do further tests, but I do believe that impact was changing to JsonObjectonce it is an interface instead of a defined type as we had on BaseDocument. It might impact the serialization.

I will create a test scenario this evening.

On my side, I could not reproduce the issue. I tried using the Sample on Java-SE with this entity here:

@Entity
public record Hero(

        @Id
        String id,

        @Column
        String name,
        @Column
        String descriptor,

        @Column
        String power) {

So, I tried using the previous version and applied to the new one.

I believe that might be a super specific case.

[m4ttek]

@otaviojava I think that the biggest problem is that @Id annotation represents different value now. It used to be "canonical id" of a record in arango collection.

[otaviojava]

@m4ttek, the issue is finding the objects once we have different mapping.

Hey @rashtao what do you think of returning to ID?

Another option would be setting a properties to let the user define which one will be the Id annotation.

[otaviojava]

@m4ttek I'm creating some tests using your sample; the unique broken point is the update method that is looking only for _dev. Could you check this?

I will fix this scenario. Do you find another issue?

Please let me know so I can fix it.

The JSON serialization does not break.

[otaviojava]

@rashtao @m4ttek
Could you review this one?

eclipse-jnosql/jnosql-databases#306

I will merge, and I will release a SNAPSHOT version; please, check if I miss something.

Thanks.

In summary, I've created a scenario and test where the entity has the default value at Id and did the modifications.

[m4ttek]

@otaviojava I've just tested it and it looks better now, but I still cannot share ArangoDatabase instance with other places in code directly where I am dependent on Jackson capabilities and annotations - I would need to be able to change serialization system.

Nevertheless, many thanks!

[otaviojava]

@m4ttek we need to think more about how to archive it

[rashtao]

@m4ttek
the mapping of fields annotated with @Id has changed in eclipse-jnosql/jnosql-databases#293

Previous versions of JNOSQL mapped @Id fields to _id document attribute, but this was not correct. In fact in ArangoDB, _id field is read-only (the database ignores the values set by the client) and auto-generated by the database (concatenating <collection-name>/<_key>).

With these changes in place, you can map _id and _key fields by annotating them in this way:

    @Id("_key") 
    private String key;
    
    @Column("_id") 
    private String id;

@otaviojava , as next step I would suggest allowing database implementations specify the default value for @Id annotation. This value, if set, should take precedence over jakarta.nosql.Id#value(), i.e. in:

jnosql/jnosql-mapping/jnosql-mapping-reflection/src/main/java/org/eclipse/jnosql/mapping/reflection/Reflections.java

Lines 293 to 306 in 84aaf3d

	/**
	* Gets the id name, so it reads the {@link Id#value()} otherwise {@link Field#getName()}
	*
	* @param field the field
	* @return the column name
	* @throws NullPointerException when the field is null
	*/
	String getIdName(Field field) {
	requireNonNull(field, "field is required");
	return Optional.ofNullable(field.getAnnotation(Id.class))
	.map(Id::value)
	.filter(StringUtils::isNotBlank)
	.orElse(field.getName());
	}

This would allow for:

@Entity
public class Book {

    @Id
    private String id;

    // ...
} 

to be mapped automatically to field _key when using ArangoDB, without the need of specifying @Id("_key").