Configuration-level Optimistic Locking with Longevity

Longevity - a persistence framework for Scala and NoSQL - has been built from day one to isolate persistence concerns behind a clear, consistent, and easy to use API. The power of this design principle is demonstrated by how easy it is for you to bring optimistic locking to your application. All you have to do is set a configuration flag.

Longevity is growing to full maturity, and most features you would expect from a persistence framework are in place. Our 0.10.0 release brings many incremental improvements - including support for controlled vocabularies. But the central feature of this release is configuration-level optimistic locking.

Let's say you're starting a new Scala project, and you want to use a NoSQL database such as MongoDB or Cassandra. You start looking around for tools to help integrate the database and the application. You hear great things about Slick, but unfortunately, it's only for relational databases. For Mongo, there are good libraries such as Casbah and ReactiveMongo. For Cassandra, there is Phantom. All these options will give you as much as the Java drivers, as well as their own styles of support for translating between database records and Scala objects. But you still have to write and maintain the translations yourselves, as well as other repository methods.

You picked a good library and you are plowing ahead with an early version of your application. You build out some repositories, and find that you are going to need integration tests that hit a real database, to assure your repositories continue to work properly. Your tests need test data, so you develop a little library for producing test data for your domain. The next feature needs a new query, so you write a repository method and a test for that. You are rapidly producing persistence infrastructure that you are going to have to maintain indefinitely.

Earlier on, you planned on coming back and implementing optimistic locking when the system matured a little bit. Now, you're wondering if it would be worth the effort. Let's say you were to go ahead with it. Now, every one of your domain classes has a new rowVersion field in it. The JSON converter picks it up, and it starts making its way into the API. One of your API clients notices the new field and asks about it. There's nothing to say but it shouldn't be there, please ignore it, and we'll get rid of it soon.

Choosing longevity for a persistence framework would have saved you a lot of trouble. It entirely handles the translation between database records and Scala objects. It produces fully functional repositories for you, out of the box. It provides you with integration tests to assure your repositories are working. It produces test data for your domain. And you get optimistic locking with the flick of the switch. No need to add any row version fields to your domain objects.

Longevity 1.0 is on track to be released this fall. It's all in the Current and Backlog columns of this story board. And the Icebox column there will give you a good sense of the places longevity is headed. To get a better idea of what longevity already does for you, check out the feature list, the Getting Started Guide, or browse the user manual table of contents.

If there is a feature you are interested in and you don't see it or it's not implemented yet, by all means, please let me know! There's a good chance we can get you that feature before you need it.