使用JOOQ从单个表生成多个Java Enum

本文介绍了使用JOOQ从单个表生成多个Java Enum的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我的数据库架构中有一个表，其中包含我正在构建的应用程序的配置信息。我想根据表格的内容生成一些枚举。我目前正在构建脚本中使用JOOQ来从同一个数据库生成其他标准JOOQ类，并希望我可以通过JOOQ获得这个新功能。

I have a table in my database schema which contains configuration information for an application that I'm building. I'd like to generate a number of enums based on the contents of the table. I'm currently using JOOQ in my build scripts to generate other, standard JOOQ classes from the same database, and am hoping that I can obtain this new functionality through JOOQ.

例如，如果表格包含以下数据

For example, if the table contained the following data

Product Component PresentationOrder HydroProduct Boat 1 HydroProduct Canoe 2 HyrdoProduct Ship 3 LandProduct Car 1 LandProduct Bike 2

然后我想生成两个枚举

hydroProduct.Components { Boat, Canoe, Ship; }

和

landProduct.Components {Car, Bike; }

其中hydroProduct和landProduct是包，枚举都称为组件。

where hydroProduct and landProduct are packages, and the enums are both called Components.

精确的详细信息可供争夺（例如，我可以使用不同的命名约定，因此欢迎任何建议），但是主体（两个枚举来自一个表，基于其中的数据，至少对于这个问题，是我需要的东西。

The precise details are up for grabs (e.g. I'd be fine with different naming conventions, so any suggestions are welcome), but the principal (two enums from the one table, based on the data therein) is, at least for this question, the thing that I need.

阅读完JOOQ文档后，我发现生成枚举曾经是JOOQ的一部分，然后删除。我无法看到在JOOQ中做我想要的显而易见的方式，但它是一个非常棒的库，所以我猜可能有一个。

Having read the JOOQ docs, I see that generating Enums was once a part of JOOQ, and then removed. I can't see the "obvious" way of doing what I want in JOOQ, but it's a pretty amazing library, so I'm guessing that there might be one.

编辑

一些评论者质疑整体方法，据我所知。我想避免那种谈话 - 我基本上不可能在这个论坛上讨论这种设计水平。这种方法（基于DDL和SQL的代码生成）在我的组织内经过了很好的测试，并且进行了大量的设计审查。

A number of commenters have questioned the overall approach, which I understand. I'd like to avoid that kind of conversation - it's basically impossible for me to debate that level of design over this forum. This approach (code generation based on DDL and SQL) is very well tested within my organisation, and has had a very large amount of design scrutiny.

仅供记录，这是管道的概述。我正在投入，因为我感谢人们花时间考虑我原来的问题，并且我想明确这个问题是如何适应我们的整体开发系统的。

Just for the record, here's an outline the pipeline. I'm putting it in because I appreciate that people have spent time considering my original question, and I'd like to make it clear how the question fits into our overall dev system.

Project One包含一些引导类，一些DDL和一些包含整个系统使用的数据常量的SQL脚本。它的输出包括（除其他东西），一些.jar文件包含生成的类的编译版本。这些基本上包括我们系统其余部分用于通信的核心商定词汇。

Project One holds some bootstrapping classes, some DDL and some SQL scripts that contain the data constants that our overall system uses. It's output includes (amongst other stuff), some .jar files containing compiled versions of classes generated. These basically comprise the core agreed vocabulary that the rest of our system uses to communicate.

项目二拥有java源代码，它利用项目一生成的各种人工制品。在项目二被编译之前，可以假设已经生成了来自项目一的人工制品。因此，例如，从项目一中保存的数据生成的枚举可以在编译时在项目二中使用。

Project Two holds java source code, which makes use of the various artefacts generated from project one. Before project two ever gets compiled, artefacts from project one can be assumed to have been generated. So, for example, an Enum generated from data held in project one can be used, at compile time, in project two.

我们的构建脚本构建项目一，并制作项目二的可用产出。这包括生成Eclipse项目文件，以便项目二的用户可以为项目的任何分支签出，构建和打开eclipse，并且只是工作。

Our build scripts build project one, and make the outputs available for project two. This includes generating Eclipse project files so that users of project two can check-out, build, and open eclipse for any branch of the project and it "just works".

还有其他项目（包括不同语言，例如Javascript）也使用项目1生成的人工制品。

There are other projects (including in different languages, e.g. Javascript) that also make use of the artefacts generated by project one.

这种方法的主要好处是，当项目1中的数据发生变化，而项目1中的类和枚举的定义因此发生变化时，项目2反映了这种变化与编译时错误，而不是运行 - 时间错误。这在实践中的好处是绝对巨大的。有一个设置成本，是的，但在我们的经验中，像JOOQ这样的工具（我们用来生成项目1的输出）使我们比以前更加高效。

The key benefit of this approach is that, when the data in project one changes, and the definitions of classes and enums in project one therefore change, project two reflects this change with compile-time errors, rather than run-time errors. The benefits of this in practice are absolutely enormous. There is a setup-cost, yes, but in our experience tools like JOOQ (which we use to generate the outputs of Project 1) have made us incredibly more productive than we used to be.

特别是我们提供桌面，浏览器和J2EE组件的情况，他们都需要一起交谈。

This is especially the case where we ship desktop, in-browser, and J2EE components and they all need to talk together.

推荐答案

这不是一个详尽的答案，因为这个问题有点自以为是，但我可以在jOOQ中提供一些关于此功能历史的权威背景：

This won't be an exhaustive answer, as the question is a bit opinionated, but I can provide some authoritative background on the history of this feature in jOOQ:

在阅读了JOOQ文档后，我发现生成Enums曾经是JOOQ的一部分，然后被删除。

Having read the JOOQ docs, I see that generating Enums was once a part of JOOQ, and then removed.

是的，删除的原因正是因为当时存在的实现远远不够复杂，无法适应您的特定用例。

Yes, the reason for removal was precisely because the then-existing implementation was far from sophisticated enough to accommodate, for instance, your particular use-case.

代码生成是一种非常特殊的科学，维护配置API非常困难向后兼容，可以容纳所有可能的用例...例如，你想要将主数据的一部分映射到包，类名是常量，订购自定义的事实是相当特殊的，而不是通用的。

Code generation is a very ad-hoc "science" and it is extremely difficult to maintain a configuration API backwards compatibly, which can accommodate all the possible use-cases... For instance, the fact that you want to map parts of your master data onto packages, class names being constant, ordering custom is rather particular, not generic.

此外，应该从哪里引用生成的枚举？原始实现通过生成的代码中的枚举引用替换外键（例如，整数）。在某些情况下，这可能根本不是您想要的，您希望以原始形式加入主数据，而不是生成的枚举。

Furthermore, where should generated enums be referenced from? The original implementation replaced foreign keys (e.g. Integers) by enum references in the generated code. This might not at all be what you want in some cases, where you do want to join the master data in its raw form, not as a generated enum.

长篇故事简而言之，这是jOOQ 1.x中一个急剧增加的功能，在创建jOOQ 3.x所需的主要内部重构期间极难维护，这就是它被删除的原因。

Long story short, this was an eagerly added feature in jOOQ 1.x, which was extremely hard to maintain during major internal refactorings that were needed to create jOOQ 3.x, which is why it was dropped.

我无法看到在JOOQ中做我想要的明显方式，但它是一个非常棒的库，所以我猜可能有一个。

I can't see the "obvious" way of doing what I want in JOOQ, but it's a pretty amazing library, so I'm guessing that there might be one.

不是开箱即用的。我建议使用像 Velocity 或 Xtend 并在构建过程中手动生成代码。事实上，您甚至可以生成自定义 转换器或绑定 实现将您的枚举绑定到相关的引用列。

Not out of the box. I'd recommend using a templating language like Velocity or Xtend and generate the code manually as part of your build. You could, in fact, even generate custom Converter or Binding implementations to bind your enums to the relevant referencing columns.