New SQLite Back End for Longevity

Longevity release 0.20.0 is out, featuring the following changes:

• Added a SQLite back end.
• Trying to be a bit more formal, changed occurrences of "Mongo" with "MongoDB" in the public API.
• Replaced "partition key" terminology with "primary key". I was undecided about this for a long time leading up to implementing the feature, and I think I made the wrong choice when the time came. "Partition key" is a little over specified for distributed database scenario. It's a little more general to posit that a database table can have multiple keys, but can more powerfully optimize a single one of those keys at your choosing. Now that I have three very different back ends, it's getting harder and harder to overfit longevity to a single database technology!

Keep reading to learn more about the new back end:


Over the last year or so, I've gotten a small handful of requests for a SQLite longevity back end. This sort of surprised me at first, but now that I've thought it over a good deal, and had some experience using SQLite, it makes a lot more sense to me.

SQLite is a very lightweight way to get started doing persistence. You don't need to install anything on the machines that are going to run it - you just need to supply the SQLite jar on your classpath. SQLite stores your database in a single file in the local filesystem. This incredible ease of use is a great combination with longevity, where you don't need to define a database schema either! Now, to get started working on a database application, all you need to do it put some longevity annotations on the classes you want to persist, like in this demo.scala example.

This use case is in contrast to existing MongoDB and Cassandra back ends. In these cases, we are probably planning on building larger, more involved applications, in which case the simplicity of using longevity keeps the total complexity of the application down. Program complexity is minimized in the persistence arena, to allow for more focus on the domain model and business needs.

A SQLite back end also brings up the very interesting possibility of building mobile applications with Scala and longevity. I'd like to give this a try on Android when I have the chance. I'm not sure what the Scala story is on iOS these days, but I know you can use SQLite over there.

In any event, the SQLite back end is in place! I hope you all love it. This is more or less a vanilla JDBC implementation, so it probably shouldn't be too far from working in conjunction with other JDBC drivers. Please experiment with other drivers if you like. I've left open a back door configuration variable longevity.sqlite.jdbcDriverClass that you can use. If there are any simple changes I can make to get longevity working with the JDBC driver of your choice, I will be more than happy to make them. Unfortunately, I am already maintaining four longevity back ends, and I won't be able to officially support any more than that on my own. Please considering contributing!

I'm not really sure what's going to come next in longevity. I still think support for optional properties is fairly critical, and that will probably be my next feature. But I'm also starting to think pretty seriously about the schema migration story. I have a pretty clear idea of what I want to do there, and it's going to be awesome. It's also a critical feature for the longevity user experience.