> I am not sure why you make a specific distinction between custom enums > and custom types. A custom enum happens to be a custom type in my > view.
A mapper for enums can be generated by jOOQ with the slightly adapted design you originally proposed. It will be useful to 80% of the users wanting to provide jOOQ with meta-information about their custom enum types. It will be very simple to configure and to use, there is little effort involved. A mapper for arbitrary custom types cannot be generated. You can still consider your custom enums to be custom types and define your custom, non-generated mappers though. This is for power-users wanting to go much farther than just mapping simple enum types, like Pay (and others) originally did. Separating the two notions helps keeping things simple and focused for enum types. I am not aware of any JPA implementation that has a simple solution like the enum-mapper code generation like you originally proposed it. However, many JPA implementations provide the "power-user solution" for arbitrary mapping. > It is also unclear in your e-mail how the mapper is defined (in the > generator or by users in their code). > I tend to think that in-code definition is more flexible, allows all > sort of mapping rules (with caching, boxing, etc) than trying to > generate such code. That's why it is distinguished. If you don't need the flexibility for enums, let jOOQ generate the enum mapper. If you need it, provide jOOQ with a mapper reference. > Moreover, the user needs to establish the mapping > rules whatever approach but they do not need to refer to model > generation related files and do not need to re-generate if a > refactoring changes their internal enum/types mapping logic. Then they shouldn't choose to generate mappers but go for the second approach and provide jOOQ with a custom mapper reference. > jOOQ could provide a default enum mapper for enums that implement a > particular interface and in which mapper a map is built for later > lookup. That is not possible without reflection, because of the intValue() method. That "default enum mapper" needs to know how to map an instance of SomeEnum to its SomeEnum.intValue() and vice versa. Of course, generated code will extend an AbstractEnumMapper class (as opposed to simply implementing the interface), handling some base logic, to keep generated code slim. > With a code approach, their needs to be a clear place where to > establish the mappers. It could be registered in the Settings (like in > my previous e-mail), or it could also be in the field itself: I prefer the Field. Or more specifically, the field's DataType. I can see the more advanced use-case for replacing the default mapper by any compatible mapper in the Settings. > MyTable2.MyEnum.setMapper(myEnumMapper); > // Assume MyJOOQEnumImpl implements JOOQEnum interface with getLiteral() > MyTable3.MyOtherEnum.setMapper(new JOOQEnumMapper(MyJOOQEnumImpl.class)); > The above code would have to be called once when the application > starts and it would be the user's responsibility. I'd like to avoid delegating initialisation of jOOQ's internals to client code. That can go terribly wrong. MyTable2.MyEnum is to be considered an immutable column reference. It shouldn't be possible to change its configured state like this. If mappers are referenced from a Field's DataType, however, loading the generated classes takes care of loading (and initialising) the generated mappers automatically. Anyway, your idea and mine aren't contradictions... > Consider my code where I have about 200-300 enums. I would have > 200-300 mapping lines, but they would be the same: I would only have > to create my generic custom enum mapper (similar to the JOOQ enum > described above) and instanciate it for every enum. Very readible in > my view (don't forget that the field and the mapper are typed, so I > cannot plug a wrong mapper on that field). Yes, ultimately, this is going to the right direction.
