2

I am building an application using Scala 2.10, Salat and Play frmework 2.1-RC2 (will upgrade to 2.1 release soon) and MongoDB.

This is a faceless application where JSON web services are exposed for consumers. Up until now JSON was converted into Model object directly using Play's Json API and implicit converters. I have to refactor some case classes to avoid 22 tuples limit and now instead of flat case class I'm now refactoring to have an embedded case(and embedded MongoDB collection).

Web service interface should remain same where client should still be passing in JSON data as they were before in a flat structure but application needs to map them into proper case class(es) structure. What's the best way to handle this kind of situation. I fear of writing a lot of conversion code <-> Flat JSON <-> complex case class structure <-> from complex case classes to flat JSON output again.

How would you approach such a requirement? I assume case class 22 tuple limit may have had been faced by many others to handle this kind of requirements? How would you approach this

user2066049
  • 1,371
  • 1
  • 12
  • 26

1 Answers1

1

The Play 2.1 json library relies heavily on combinators (path1 and path2). These combinators all have the same 22 restriction. That gives you two options:

  1. Don't use combinators and construct your objects the hard way: path(json) will give you the value at that point in the path. Searching for 'Accessing value of JsPath' at ScalaJsonCombinators will give more examples.
  2. First transform the json into a structure that does not have more than 22 values in a single object and then use the normal combinators. More information about transforming can be found here: ScalaJsonTransformers
EECOLOR
  • 11,184
  • 3
  • 41
  • 75
  • Thanks EECOLOR. So would you approach this the 1st way to manually map path to a nested case classes, and then for the response again map nested case classes to a flat JSON? – user2066049 Feb 18 '13 at 11:59
  • I am not quite sure what I would do. On te one hand I would like the json to reflect the structure of my case classes. Transformation would be better for that case. On the other hand it feels wrong to convert twice (json -> json -> case classes). You mention that you use MongoDB, would it be an option for you to transform directly to MongoDB json? – EECOLOR Feb 18 '13 at 12:36
  • Originally I was directly dumping incoming JSON into MongoDB and sending back Mongo JSON to the consumer. But having strongly typed JSON mapped objects seemed quite required to validate,pass around JSON documents via mapped objects into other part of app.May be incoming JSON can be manually mapped to complex case classes but outgoing response, from Mongo, can directly be sent to the consumer (without mapping into case objects)? Since all DB operations happens via Salat APIs which accepts case objects and returns case objects. An interesting decision to make which way to go? – user2066049 Feb 18 '13 at 15:21
  • I understand it's hard. You could check [this question](http://stackoverflow.com/questions/4152223/why-are-scala-functions-limited-to-22-parameters) to see some of the reasons of that limitation. Also, please don't forget to do the same for questions which you asked previously, whenever applicable. You can find them in your profile. If no answer is applicable and you have already solved the problem by yourself, then you're eligible to post it as an answer and accept it. – EECOLOR Feb 18 '13 at 15:54