{"id":48,"date":"2014-06-19T20:12:09","date_gmt":"2014-06-19T20:12:09","guid":{"rendered":"http:\/\/www.mbarsinai.com\/blog\/?p=48"},"modified":"2014-06-20T02:24:42","modified_gmt":"2014-06-20T02:24:42","slug":"anorm-and-duplicate-column-names","status":"publish","type":"post","link":"https:\/\/www.mbarsinai.com\/blog\/2014\/06\/19\/anorm-and-duplicate-column-names\/","title":{"rendered":"Anorm and Duplicate Column Names"},"content":{"rendered":"

A bit of a technical post, just in case someone else hits this problem, e.g. while working through Play for Scala<\/a> book (which I heartily recommend). That’s how I stumbled on this issue.<\/p>\n

Anorm<\/a> is an interesting alternative to ORMs. This is pretty much going against the flow of “let us write your SQL for you”, so they have some explainin’ to do. Anorm sticks to native SQL, and make it easier to parse result rows into objects. One way of making it easy are SQL row parser combinators.<\/p>\n

The idea is this: parsers take column values from an SQL result row, and return a Scala object. Combining the parsers yields tuples, that can later be parsed into Scala objects (normally, some case class).<\/p>\n

So that’s all fine and dandy, but the code below produces unwanted results:<\/p>\n

\r\nval prodsAndItems =  SQL(\"\"\"\r\n    SELECT p.*, s.* FROM products p INNER JOIN stock_items s \r\n    ON p.id = s.product_id\r\n    ORDER BY p.id\r\n    \"\"\")\r\n\r\n  val productParser: RowParser[Product] = {\r\n    long(\"id\")~long(\"ean\")~str(\"name\")~str(\"description\") map {\r\n      case id~ean~name~description => Product(id, ean, name, description)\r\n    }\r\n  }\r\n  \r\n  val productsParser: ResultSetParser[List[Product]] = { \r\n    productParser *\r\n  }\r\n\r\n  val stockItemParser: RowParser[StockItem] = {\r\n    long(\"id\")~long(\"product_id\")~long(\"warehouse_id\")~long(\"quantity\") map {\r\n      case id~prodId~wareHouseId~quantity => StockItem(id,prodId,wareHouseId,quantity)\r\n    }\r\n  }\r\n\r\n  val stockItemsParser: ResultSetParser[List[StockItem]] = {\r\n    stockItemParser*\r\n  }\r\n  \r\n  val productStockItemParser: RowParser[(Product, StockItem)] = {\r\n    productParser ~ stockItemParser map (flatten)\r\n  }\r\n\r\n  def selectAllProductsAndItems: Map[Product,Seq[StockItem]] = DB.withConnection{ implicit c =>\r\n    val res:List[(Product, StockItem)] = prodsAndItems.as( productStockItemParser * )\r\n    res.groupBy( _._1 ).mapValues( _.map(_._2) )\r\n  }\r\n<\/code><\/pre>\n
This is a classic case of products, warehouses and stock items (product quantities that are stocked in warehouses). You would expect the call to  selectAllProductsAndItems<\/code> to return a map object mapping products to their stock items. Instead, it returns a set of new products that don’t exist in the database, and maps a single stock item to each one.<\/p>\n
Now, I love creating new products. I just don’t want my data access layer to do it for me. Enough of this “machines replacing people” zeitgeist.<\/p>\n
Why was Anorm doing this? (spoiler alert from here on)
\nBoth stock_items<\/code> and products<\/code> have a column called “id”. The basic parsers (defined in  stockItemParser<\/code> and productParser<\/code>) call the columns by their names, and so get ambiguous results.<\/p>\n
The solution turns out to be pretty simple (as always) – reference the column by its full name: “products.id” instead of “id”. Over to you, Peg:<\/p>\n