Converting from camel case TO field name

[Robert DiFalco]

It there a utility in JOOQ to convert a Java Bean field name like "phoneNumber" to the Field<?> name of "phone_number"? Actually, just getting the Field<?> by "phoneNumber" would be great too.

Thanks

[Lukas Eder]

There are utilities that go the other way round, i.e. from "phone_number" to "phoneNumber". I'm think that Spring might have such utilities, though. And Jackson also does:

http://stackoverflow.com/q/10519265/521799

Hope this helps,

Lukas

2015-09-14 1:22 GMT+02:00 Robert DiFalco <robert....@gmail.com>:

It there a utility in JOOQ to convert a Java Bean field name like "phoneNumber" to the Field<?> name of "phone_number"? Actually, just getting the Field<?> by "phoneNumber" would be great too.

Thanks

--
You received this message because you are subscribed to the Google Groups "jOOQ User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jooq-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lukas Eder]

I've registered an issue for this. Would certainly be very useful to expose such an API also in jOOQ's runtime:

https://github.com/jOOQ/jOOQ/issues/4544

[Robert DiFalco]

Underlying this, it would be nice to have a fluent interface using a non-JOOQ Java Bean that can translate from bean fields to database fields transparently. The into works very nicely for the other way around (i.e. query results). 

You received this message because you are subscribed to a topic in the Google Groups "jOOQ User Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jooq-user/_8KYcum-8H4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jooq-user+...@googlegroups.com.

[Lukas Eder]

You mean Record.from()? It's the inverse of into(). But there's currently no way to override the default, before we implement https://github.com/jOOQ/jOOQ/issues/2520, the "RecordUnmapper"

[Robert DiFalco]

Thanks Lukas, unfortunately it does not handle Optional<T>.

[Lukas Eder]

2015-09-15 17:52 GMT+02:00 Robert DiFalco <robert....@gmail.com>:

Thanks Lukas, unfortunately it does not handle Optional<T>.

Hmm, good point. We should certainly add Optional support to org.jooq.tools.Convert (https://github.com/jOOQ/jOOQ/issues/4565), and perhaps to other data type conversion methods.

Would you mind sharing a little more insight into your use-case? What is your current usage of Optional and what are your expectations towards jOOQ in this area?

[Robert DiFalco]

For me, my beans are parsed from JSON and allow partial updates. So, for example, I can PUT /user/1 {"emailAddress": "f...@gmail.com"} in order to only update the email_address. So I write my bean to record code like this:

    private static UserRecord newRecord(UserBean bean) {

        UserRecord record = new UserRecord();

        bean.getFirstName().ifPresent(record::setFirstName);

        bean.getLastName().ifPresent(record::setLastName);

        bean.getEmailAddress().ifPresent(record::setEmailAddress);

        bean.getPhoneNumberE164().ifPresent(record::setPhoneNumberE164);

        return record;

    }

So if a getter uses Optional I suppose I would want it to work like this. Of course other people don't see it as good practice to have a getter return an Optional at all. But for my use case it works well to tell the difference between a specified value and an absent value that has been parsed from JSON. 

R.

--

[Lukas Eder]

Hi Robert,

Thanks for this feedback (and sorry for the delay). I can see how this would be very useful, indeed. So, a simpler version of your code would do the same via reflection, when calling

    private static UserRecord newRecord(UserBean bean) {

        UserRecord record = new UserRecord();

        record.from(bean);

        return record;

    }

But this semantics cannot be hard-wired into jOOQ because it's not the only valid / useful use of Optional. For instance, your logic won't be able to model the presence of a JSON "null" value. As always with the "null" / Optional discussion, we'll wind up with several useful semantics for "absent values":

- NULL (the actual SQL NULL / UNKNOWN value)

- DEFAULT (the actual SQL DEFAULT value)

- "IGNORE" (the semantics that you have implemented, or that jOOQ models via Record.changed())

I suspect we better wait with adding new features around Optional in this area...

Cheers,

Lukas

--

You received this message because you are subscribed to the Google Groups "jOOQ User Group" group.

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