When to use Mapper or Record in Lift?

Question

I would like to understand what are the use cases, advantages and inconveniences of choosing to use Record , Mapper or even both, in a Liftweb application.

This question came up when I tried to:

• create a tree like structure for the model classes
• create a similar tree like structure for rendering of the classes in a page
• ensure different classes in the tree can be in different states at the same time. One is in the EDIT or CREATE state and the other in the VISUALIZE state for example.
• model classes can be created, read or saved to a RESTful Web Service that is already functioning.

I'm putting the use cases here just for the record. You can answer in a more general way.

Diverting

I just found out this thread that discusses some point about Mapper and Record where it states that Record is the way to go. In spite of that, mapper has much better documetation and will be supported for at least 3 more years. – Diverting

Did I mention that the Mapper stack seems more complete than the Record stack? Anyoone has some hands on experience with both and can talk a little bit about that? – Diverting

Tim is 100% WRONG and should not me spreading misinformation. Record is NOT a replacement for Mapper. Each has its own focus (Mapper/JDBC Record/generic persistence). – Pollack

Answer 1

Mapper has been part of Lift before Lift was Lift. It's a simple "Active Record" style bridge between the database and Scala. I built Mapper based on ideas outlined here: http://web.archive.org/web/20070303054927/http://blog.lostlake.org/index.php?/archives/19-Keeping-the-meaning-with-the-bytes.html

Mapper is intimately tied to JDBC and thus relational databases. Mapper has a reasonable mechanism for building simple queries, but for complex stuff one has to hand-write SQL.

Mapper is solid but crufty.

Record is a more generic abstraction between backing store and Scala. It has weaker implementations of the ideas outlined in "Keeping the meaning with the Bytes"... and very few people notice or care.

There are Record implementations for MongoDB, CouchDB, Squeryl and other storage mechanisms. Writing a new back-end is a few days of work.

Record has a lot of "anomalies" and each back end has its own quirks. The current Record owner has embarked on a wholesale refactoring of Record.

I do not think either Record or Mapper will give you tree-like structures "out of the box" unless you're using the MongoDB backend and in that case, your tree structures will be based on JSON documents rather than relations.

Pollack

This was more than I was looking for. Thanks. On a side note, my "persistence" is behind a RESTful service. So, I will implement my Record classes that load/save to that RESTful service. Taking what you said in account, maybe I should look at MongoDB to see how it is done there and loosely base my code on it. :) – Diverting

The link about "keeping the meaning with the bytes" is also a nice read. – Diverting

Answer 2

Well, the Mapper and Record libraries are only different abstractions for the database access in Lift applications. Record is the newer one and is considered to substitute Mapper one day. At the moment Record supports NoSQL databases like CouchDB and MongoDB. If your data model fits into the NoSQL world, try Record. Otherwise you can use Mapper in connection with a typical relational database.

I hopefully mentioned some interesting points for you.

Sleepless

Record also supports Squeryl - relational approach. – Ismaelisman

Indeed, it does. Good to know. But important for the questioner: Squeryl is another ORM framework on top of Record. So, you have to learn two APIs. But imho Squeryl is one of the best database abstractions you can use with Scala. – Sleepless

Record is NOT a replacement for Mapper. – Pollack

In fact as it is mentioned at 'your' Lift Wiki: assembla.com/spaces/liftweb/wiki/Record To sum up for non-committers: Record is an API to enable the use of many different database abstractions in Lift and Mapper is one of this abstractions? :-) – Sleepless