Open beargiles opened 1 year ago
Some of my most enjoyable hours have been spent reading about jOOQ. It is cool stuff.
My vision for PL/Java has been to avoid requiring any other particular library or component, so users are free to prefer whatever, but I'm certainly in favor of features to support, or identifying and removing obstacles to, easy use of jOOQ for those who wish.
If, of course, those features can be added or obstacles removed without a large jOOQ-specific maintenance burden.
This is either a vision or a fever dream. I'm not sure which.
In a nutshell jOOQ is an integration tool that's designed to provide a consistent type-safe interface to multiple databases. It does this by rewriting queries with the database-specific syntax (e.g., pagination), and even has support for functionality that the database lacks. E.g., it supported a 'merge' function for PostgreSQL long before PostgreSQL added it.
It can produce the appropriate schema from the java classes, or the java classes from an existing schema.
I mentioned it's type-safe - it uses interfaces/classes like
Some people like to define wrappers that use meaningful names, e.g., 'getName() { return value1() }'
It also supports user defined types: UDT, UDTRecord. It's much easier to understand if you look at the examples.
It occurred to me that it should be possible to define a pljava UDT in a way that's consistent with jOOQ but introduces no dependencies on jooq outside of a new pljava-jooq directory.
The usage would be similar to the existing conversion from a schema to java. There would be a maven plugin that takes a pljava jar and extracts a usable schema from it. The rest of the conversion can use the existing jOOQ code. This can probably be handled with new annotations.
Another option is adding the pljava jar as a dependency but that will bring in transitive dependencies - possibly ones that conflict with the application. Using a tool to reproduce the java class(es) is safer.
There's at least one complication - our UDT classes themselves might have dependencies. E.g., anything involving cryptography might have BouncyCastle classes in its UDT. There needs to be a way to provide a list of dependencies to the user.