Enhanced DynamoDB annotations are incompatible with Lombok

[bill-phast]

Describe the Feature

Lombok is a popular system for reducing boilerplate code, especially in data-centric objects such as database entries. By annotating the class and/or member variables, it autogenerates setters and getters. This creates problems with enhanced dynamodb, because the annotations such as DynamoDbAttribute and DynamoDbPartitionKey cannot be applied to member variables, only to setter/getter functions, and the setter/getter function is not present in the source code. In DynamoDbMapper (from AWS SDK v1), annotations could be applied to functions or member variables, so Lombok worked well. It would be great if the enhanced DynamoDb library could work the same way.

Is your Feature Request related to a problem?

I'm always frustrated when I cannot use the new SDK because it is incompatible with other software that my development team depends on.

Proposed Solution

Ideally the annotations can be applied to member variables in the same manner that the SDKv1 dynamoDbMapper annotations could.
As a second-best alternative, it could allow the annotations to be applied to member variables, but ignore them; with a little work, Lombok can be set to copy annotations from member variables to the setters and getters.

Describe alternatives you've considered

The alternative is to write explicit setters and getters for all dynamo-annotation values. This would be a significant pain point, however; we will probably prefer to stay with SDKv1.

Additional Context

Lombok annotations are as follows:

@Setter
@Getter
public class Customer {
  private String id;

  private String email;

  private Instant registrationDate;
}

Functions "setId(String)", "getId()", etc. are all generated automatically, so there is no way to get the annotations onto them.

• I may be able to implement this feature request

Your Environment

• AWS Java SDK version used: 2.13.47
• JDK version used: Java 11
• Operating System and version: Ubuntu (on EC2), AWS Lambda (whatever version of Linux that is)

[debora-ito]

Marking as a feature request.

[ocind]

Lombok supports injecting Annotations to the generated Setter/Getter (although it is an experimental feature)
Lombok Getter/Setter Reference ctrl+f "onMethod"
Usage Reference

Lombok onX Reference

[bill-phast]

Lombok supports injecting Annotations to the generated Setter/Getter

Yes that could be helpful, but this feature copies annotations from the field to the setter/getter. Enhanced DynamoDB annotations cannot be put onto the field in the first place, so we still need changes before this can work.

[justinsa]

@bill-phast I'm not seeing how this is a major pain point, if I am understanding your problem statement correctly; please correct me if I have it wrong. Lombok will not overwrite an existing getter/setter if you define one, it will just ignore code generation for it.

I am currently using the enhanced DynamoDB client with this exact scenario. Example:

@DynamoDbBean
@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class ExampleModel {
    private String fieldOne;
    private String fieldTwo;

    @DynamoDbPartitionKey
    public String getFieldOne() {
        return fieldOne;
    }
}

With the Lombok feature mentioned by @ocind this is almost identical to applying the DDB annotation by itself:

@DynamoDbBean
@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class ExampleModel {
    @Getter(onMethod_={@DynamoDbPartitionKey})
    private String fieldOne;
    private String fieldTwo;
}

[pawelkaliniakit]

@justinsa
onMethod is experimental feature and according to the page: https://projectlombok.org/features/experimental/onX
"Current status: uncertain - Currently we feel this feature cannot move out of experimental status."
I wouldn't suggest to use it due to its uncertain status.

Lombok compliant solution would be to allow annotations on field level what for the provided example means:

@DynamoDbBean
@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class ExampleModel {

    @DynamoDbPartitionKey
    private String fieldOne;
    private String fieldTwo;
}

Then fieldOne would have getters and setters generated and at the same time fieldOne would be recognised as partition key by AWS SDK in V2.

[bill-phast]

@justinsa - @pawelkaliniakit has it right, with proper annotation support we wouldn't need to explicitly write getters. I think maybe what makes that so painful to us was a decision to use @DynamoDBAttribute heavily (for any field that appears in query expressions) and for a lot of enum usage that means we use @DynamoDBTyped a lot. The end result is that we need a lot of getters that should (thanks to Lombok) not be there.

[bmaizels]

The 'onMethod' is the current approved workaround for this (I had even put an example in the REAME when coding immutables) :

    @Value
    @Builder
    @DynamoDbImmutable(builder = Customer.CustomerBuilder.class)
    public static class Customer {
        @Getter(onMethod = @__({@DynamoDbPartitionKey}))
        private String accountId;

        @Getter(onMethod = @__({@DynamoDbSortKey}))
        private int subId;  
      
        @Getter(onMethod = @__({@DynamoDbSecondaryPartitionKey(indexNames = "customers_by_name")}))
        private String name;

        @Getter(onMethod = @__({@DynamoDbSecondarySortKey(indexNames = {"customers_by_date", "customers_by_name"})}))
        private Instant createdDate;
    }

Get your point about it being experimental (plus it's ugly), so we'll definitely keep an eye on this. The tricky part is there will undoubtedly also be customers that depend on the current behavior and have properties without getters and setters they would not want to suddenly start having show up in their TableSchema, and I don't want to head down the slippery slope of adding lots of opt-in feature flags for the sake of backwards compatibility which really just leaves us with the option of creating a new introspector entirely... maybe we can figure out one that works both for Kotlin and more elegantly with Lombok at the same time.

[nadernader99]

The @builder(toBuilder = true) Lombok builder feature is also incompatible with enhanced dynamodb annotations. This feature generates a method for creating a builder pre-populated with all the fields of the current object. This feature is extremely useful in the context of DynamoDb mapped immutable objects. For example, code for updating an attribute is very easy to read and more resilient to schema changes:

    Customer customer = table.getItem(customerKey);
    Customer updated = customer.toBulder().name(updatedName).build();
    table.putItem(updated);

However, the enhanced DynamoDb validation fails because it detects a 'toBuilder' getter method without an associated setter:

A method was found on the immutable class that does not appear to have a matching setter on the builder class. Use the @DynamoDbIgnore annotation on the method if you do not want it to be included in the TableSchema introspection.

Unfortunately, it is not possible to add an annotation to the 'toBuilder()' method generated by Lombok. The only work-around is to hand-code the copy builder method.

If compatibility with Lombok (a other field-based object frameworks) is being pursued, this issue should be considered as well.

[helloworldless]

I'd like to add one more suggestion that is closely related to this. When working with Lombok and @DynamoDbImmutable, I keep having to do this for derived fields:

@DynamoDbImmutable(builder = Customer.CustomerBuilder.class)
@Value
@Builder
public class Customer {

    @DynamoDbAttribute("Type")
    public String getType() {
        return "Customer";
    }

    // "Type" is a derived field (see hand-written getter above). There is no point in exposing it 
    // on the Builder. However, it is required to be on the Builder by the AWS SDK v2 Enhanced 
    // Client, so we must add this here so that Lombok adds it to the Builder
    @Getter(AccessLevel.NONE)
    String type;

    // Here's a normal, non-derived field. Notice that we use Lombok's @NonNull to enforce that 
    // this is set at object creation time, whereas we don't use @NonNull on the "type" field above
    @Getter(onMethod = @__({@DynamoDbAttribute("CustomerId")}))
    @NonNull
    String customerId;

This follows from the docs which state this as a requirement under Working with immutable data classes.

Every getter in the immutable class must have a corresponding setter on the builder class that has a case-sensitive matching name.

So ideally the Enhanced Client would support something like below, where the @DynamoDbDerivedAttribute would tell the SDK not to look for this field on the Builder:

    @DynamoDbAttribute("Type")
    @DynamoDbDerivedAttribute
    public String getType() {
        return "Customer";
    }

[bigunyak]

I also stumbled onto the issue with toBuilder support.
Would be great if you could address it, as it does make a lot of sense when working with immutable classes. 🙏