t9t / jooq-postgresql-json

jOOQ support for PostgreSQL json & jsonb

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

feat(kotlin): provide operators through extension functions

davinkevin opened this issue · comments

Hi,

First, I want to thank you for providing this library to simplify the integration of JSONB with JOOQ 👍.

My issue is about providing extension functions for Kotlin projects. Now, jooq supports Kotlin from generator to code, so it could be good to be able to use this kind of syntax:

// PODCAST.METADATA is of type Field<JSONB?>
val youtubeField = PODCAST.METADATA.objectAtPathText("youtube", "channelId")

private fun Field<JSONB?>.objectAtPathText(vararg path: String): Field<String> {
    return DSL.field("{0}#>>{1}", String::class.java, this, DSL.array(*path))
}

If you are interested, I can provide a PR for that if you let me know how do you want to proceed to integrate Kotlin code.

commented

Hello! Thanks for the suggestion. I'm a big fan of Kotlin and I think this is really a great idea! Probably if one of my Kotlin projects was using JSON with Jooq, I would have added support for extension functions myself already.

It would be really great if you would be able to work on this and provide a pull request to add it!

Please keep the following things in mind, though:

  • I've added plenty of Javadoc documentation throughout the library so far, that is available in the code and IDEs, and also externally, so it would be nice if the extension functions would also be covered in that regard (even if it's only a reference to the corresponding function in the JSON/JSONB classes).
  • If some re-use is possible, I would really prefer that (eg. in your example, re-using the JSONB.objectAtPathText function also)
  • I don't have any experience yet with providing Kotlin extension functions in a library, so I'm not sure what a good and safe approach is to ensure the library will work nicely in an Kotlin environment, but also still works without any issues in existing Java environments without Kotlin. Perhaps a separate Maven module would be prudent? It would be nice to follow best-practices for that (even though I don't know yet what they are).

I hope the above pointers are reasonable and not too much of a burden, because I don't want to kill your enthusiasm for contributing! Let me know what you think, and if you feel comfortable with the above please proceed and I'd be very happy to include your contributions.

Thank you for your answer on this subject. I'm very interested about contributing to the lib for Kotlin support 🎉.

For now, I'm working currently on a JOOQ presentation for a meetup, but as soon as this will be done, I will work on multiple PR for this evolution. I will try to do it step by step to avoid a huge MR with a lot of changes…