Scala best practices? What does your jOOQ pimp-my-library look like?

[er...@eluvio.com]

Hi All ~

I'm currently in the process of switching from slick to jooq, things are going fairly well so far, but one of the patterns I'm still trying to come up with a good syntax for is updating specific fields in a table.

For instance:

Brute force approach:

readWrite
  .update(CATALOG_USER)
  .set(CATALOG_USER.FIRST_NAME, r.firstName.getOrElse(null))
  .set(CATALOG_USER.LAST_NAME, r.lastName.getOrElse(null))
  .set(CATALOG_USER.COMPANY, r.company.getOrElse(null))
  .set(CATALOG_USER.ADDRESS1, r.address1.getOrElse(null))
  .set(CATALOG_USER.ADDRESS2, r.address2.getOrElse(null))
  .set(CATALOG_USER.CITY, r.city.getOrElse(null))
  .set(CATALOG_USER.STATE, r.state.getOrElse(null))
  .set(CATALOG_USER.ZIP, r.zip.getOrElse(null))
  .set(CATALOG_USER.COUNTRY, r.country.getOrElse(null))
  .set(CATALOG_USER.PHONE, r.phone.getOrElse(null))
  .set(CATALOG_USER.FAX, r.fax.getOrElse(null))
  .where(CATALOG_USER.CATALOG_ID === catalogId and CATALOG_USER.CATALOG_USER_ID === catalogUserId)
  .execute

If you assume the r.firstName/etc are all Option[String] values, is there a good way to conditionally add the set statement in this pattern only if its set?

Is there a pseudo builder pattern I can use?  Or what do you use to optionally add a field to the .set?

val builder = readWrite.update(CATALOG_USER)

row.firstName.map{ builder += set(CATALOG_USER.FIRST_NAME, _) }
row.lastName.map{ builder += set(CATALOG_USER.LAST_NAME, _) }
row.lastName.map{ builder += set(CATALOG_USER.COMPANY, _) }
...

  builder.build().where(CATALOG_USER.CATALOG_ID === catalogId and CATALOG_USER.CATALOG_USER_ID === catalogUserId)
  .execute == 1

Thanks,

Eric

[Lukas Eder]

Hi Eric,

Thank you very much for your enquiry. Interesting to hear about another Slick to jOOQ migration story. May I ask what your primary motivation was to use jOOQ rather than Slick?

I can't answer from an "idiomatic Scala" point of view as I'm not writing Scala too often, but one way to solve this would be by using implicit functions to translate from Option[T] to Field[T]. I wonder if we should put those into org.jooq.scala.Conversions... curious what you think. I'm thinking of:

  implicit def asField[T](r: Option[T]): Field[T] = DSL.val(r.getOrElse(null))

This way, you can automatically pass Option[T] bind values to many jOOQ API methods that accept a Field[T]. What do you think?

Of course, an entirely different option might be to use the generated UpdatableRecords. You could just write:

  CatalogUserRecord record = ...;

  record.store();

Hope this helps,

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.
For more options, visit https://groups.google.com/d/optout.

[er...@eluvio.com]

I like this:

implicit def asField[T](r: Option[T]): Field[T] = DSL.`val`(r.getOrElse(null.asInstanceOf[T]))

Still mulling over whether I don't want to update a field all the time, but it at least cleans up that specific code...notice my improvements to clean up the compiler, I think it should be added to the Conversions object.

-Eric

[Lukas Eder]

Thanks for the feedback. True, `val` must be quoted. We also have DSL.value(), which is a synonym to avoid that hassle...

I've registered a feature request for this:

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

I do have some concerns about this change, though.

1. There's a risk of introducing compile time ambiguities for those people who already use Option[T] fields via the code generator and custom Converters

2. As this will apply very broadly throughout the jOOQ DSL, I'm very curious about the compile time overhead in terms of performance

What do you think?