Underline variable support for class attributes

[gggitpl]

public class Car {

    private String numberPlate;

    public static final class Fields {
        public static final String NUMBER_PLATE = "number_plate";
    }

}

Can you add such support? Useful when using mybatis, to avoid the problem of error-prone fields in handwritten fields

[Reinier Zwitserloot]

'error-prone fields in handwritten fields' doesn't make sense to me.

We can add such support, but, given that there is already an uppercase option that uppercases the field name (without it, you'd get psf String numberPlate = "numberPlate"; with it, you get psf String NUMBER_PLATE = "numberPlate".

Now you want uppercased name for the field, and also a conversion of the fieldname to a lowercased, underscore variant. None of the options that exist now mess with the field name (After all, isn't the point to have.. field names? And not weird modifications of field names?) – whatever option we'd tag on to @FNC would be confusing.

And that's why this feature cannot happen. It's undocumentable.

There are some ways out:

1. Some proposal on how to get it done such that it wouldn't  be too confusing.

2. Introduce another annotation, presumably in a lombok.extern.mybatis package.

For #2 there's a lot more maintenance effort involved, which would probably mean it's not going to happen.

What confuses me more is that whatever 'mybatis' is, that it requires you to have constants of the form "number_plate", and that it is not possible to tell mybatis to convert numberPlate to numberplate. Are these constants for db column names, perhaps? Using underscores there is merely a far less consistently observed convention, and 'mybatis' would be the wrong name (the point of the feature would be to transmute field names into something that befits SQL conventions more. lombok.extern.sql? I don't think this is ever going to be worth writing; nobody who'd want it would discover it).

[Martin Grajcar]

On Sun, Dec 15, 2019 at 8:23 PM Reinier Zwitserloot <rein...@gmail.com> wrote:

'error-prone fields in handwritten fields' doesn't make sense to me.

:D It's error-prone to write field names manually.

 

We can add such support, but, given that there is already an uppercase option that uppercases the field name (without it, you'd get psf String numberPlate = "numberPlate"; with it, you get psf String NUMBER_PLATE = "numberPlate".

Now you want uppercased name for the field, and also a conversion of the fieldname to a lowercased, underscore variant. None of the options that exist now mess with the field name (After all, isn't the point to have.. field names? And not weird modifications of field names?) – whatever option we'd tag on to @FNC would be confusing.

And that's why this feature cannot happen. It's undocumentable.

Lombok could use existing CaseFormat converters, which are already nicely documented.

There are some ways out:

1. Some proposal on how to get it done such that it wouldn't  be too confusing.

2. Introduce another annotation, presumably in a lombok.extern.mybatis package.

For #2 there's a lot more maintenance effort involved, which would probably mean it's not going to happen.

What confuses me more is that whatever 'mybatis' is, that it requires you to have constants of the form "number_plate", and that it is not possible to tell mybatis to convert numberPlate to numberplate. Are these constants for db column names, perhaps? Using underscores there is merely a far less consistently observed convention, and 'mybatis' would be the wrong name (the point of the feature would be to transmute field names into something that befits SQL conventions more. lombok.extern.sql? I don't think this is ever going to be worth writing; nobody who'd want it would discover it).

The OP is possibly completely completely unaware of @lombok.FieldNameConstants. They may not care about naming of the constant and they may or may not need the underscores. This would be LOWER_CAMEL.to(LOWER_UNDERSCORE, fieldName). It's quite possible that mybatis can do this conversion itself, and otherwise, it should be rather trivial to patch.

I case Lombok should do this, I'd suggest to copy the CaseFormat enum from Guava and add fromFormat and toFormat options to @FieldNameConstants.

With both defaulting to CaseFormat,LOWER_CAMEL, we'd get the current behavior.

 

On Sunday, December 15, 2019 at 5:18:29 PM UTC+1, gggitpl wrote:

public class Car {

    private String numberPlate;

    public static final class Fields {
        public static final String NUMBER_PLATE = "number_plate";
    }

}

Can you add such support? Useful when using mybatis, to avoid the problem of error-prone fields in handwritten fields

--
You received this message because you are subscribed to the Google Groups "Project Lombok" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/project-lombok/2dd1221c-5d12-485a-9664-38fd10b1a485%40googlegroups.com.

[Reinier Zwitserloot]

This CaseFormat thing is definitely crucial to this feature; a shame it's in guava and not core, but we can just copy it, indeed.

So, we're down to use cases: Can mybatis work around this, and is this kinda thing useful anywhere else?

To unsubscribe from this group and stop receiving emails from it, send an email to project-lombok+unsubscribe@googlegroups.com.

[gggitpl]

When naming database fields, it is generally recommended to use underscores to split words, and java is the camel case method.

When some frameworks encapsulate the query, they only need to call the method and then pass in the field to be queried. At this time, the camelcase variable name to the underscore, which is the conversion from the java attribute to the database field, is required.

NUMBER_PLATE = "numberPlate" numberPlate = "numberPlate" is not very helpful to me. When using it, I also need to use CaseFormat to do a conversion. For example, jooq uses the maven plugin to generate references to database fields. I think it is more elegant to use lombok, Personally, I don't like code generation tools very much, sometimes they generate things that I don't need.

在 2019年12月16日星期一 UTC+8上午3:23:35，Reinier Zwitserloot写道：

[gggitpl]

jooq jfinal will have such a need, but currently they all provide code generation
在 2019年12月16日星期一 UTC+8下午7:36:20，Reinier Zwitserloot写道：

To unsubscribe from this group and stop receiving emails from it, send an email to project...@googlegroups.com.

[Reinier Zwitserloot]

But why is it lombok's job to do this case conversion? JOOQ should be doing it if this is the recommended way to do it. This feels like lombok being used to fix a crappy API. That's not something we want lombok to do unless the usage of said API is extremely widespread and a fix seems hopeless (which seems highly unlikely; surely somebody would fork!)

[Raja Chaitanya Rekapalli]

@FieldNameConstats is a wonderful annotation while writing complex SparkSQL queries in Java.  However, we ran into the same problem of case conversion of field names while using Spring JPA + Postgres along Apache Spark.   By default, Spring JPA (hibernate) is creating database field names with underscores when using with Postgres.  While there are strategies to force column names to be created the same way as field names in a class, this poses another challenge at the database side, where we have to quote the fields while are writing queries (as postgres is case sensitive with object names).  In order to address various case conversion issues we can have following two approaches:

1) A different annotation for each case. For example, @FieldNameConstantsSnakeCase, @FieldNameConstantsPascalCase

2) An extension to @FieldNameConstants that take a value for case. For example, @FieldNameConstants(nameCase="PascalCase"), @FieldNameConstants(nameCase="CamelCase")