Skip to content
Ryan edited this page Oct 17, 2018 · 8 revisions

Welcome to the forsuredbcompiler and forsuredbapi - The open-source code generator and querying primitives portion of the anti-ORM forsuredb project. The project's documentation page has moved to http://forsuredb.org.

The other parts of the forsuredb project are:

  • The platform integration library
  • The DBMS integration library:
  • The tooling:
    • forsuredbplugin to make configuring forsuredb easier by way of a gradle extension

What does forsuredbcompiler do?

forsuredbcompiler analyzes your source code at compile time and generates two things for you:

  1. A typesafe, fluent database querying API (like a DAO) based upon the interface you have declared.
  2. A set of database migrations that should be applied at runtime to migrate your app's schema to the one that the API generated in step 1 expects (don't worry--the sqlitelib understands how to generate the SQL and the forsuredbandroid library understands when to apply the SQL)

Philosophy

forsuredb is pretty opinionated about how client applications should handle persisted data. forsuredb is also opinionated about how developers should be spending their time.

Deliver Faster by focusing on "what" rather than "how"

Especially on Android, database migrations and updating database queries that occur throughout your app takes time. Because you get a custom querying API generated for you, you don't need to write a custom migration or maintain your database version. This frees you to spend time on the app's business objectives--adding features/fixing bugs, etc.

Reduce Object overhead

The jdbc ResultSet or Android Cursor does a good job at giving you access to exactly the parts of the data that you need. Unfortunately, this often comes at the expense of having a clean API. For example, with an Android Cursor, you have to know either the column name or the column index as well as the data type at the point you want to access the data.

On the other hand, ORMs require you to create an object corresponding to each record of a relation returned by a query. And in Room, you even must produce the SQL required to return the records. So this is perhaps a nice API, but it would be nice to not have to create many objects when you may be returning hundreds/thousands of records in a query.

forsuredb gives you both. Idiomatic forsuredb has you create one object that is your table's API and one object that is your ResultSet/Cursor, allowing you to pull out individual fields of records as opposed to pulling out the whole record as an object.

Fast Prototyping and Declarative Syntax

forsuredb provides a declarative, annotations-based syntax that puts no implementation responsibility on the application developer. This makes it really quick to spin up a data schema to get a feel for what kinds of things your database can do. If your current schema doesn't meet your needs, just change the schema and use the dbmigrate task provided by the forsuredbplugin gradle plugin to edit the schema.

Plugability is Awesome

Forsuredb has been split such that code generation can be utilized to work with different platforms (eg JavaFX, Android, ...) and different DBMS implementations (SQLite, MySQL, ...) and different serialization libraries (Java Serializable, Gson, Jackson, protobufs, etc). As the library evolves, it will only continue to become more pluggable. In fact, if you implement the interfaces in the forsuredbapi library, you could plug in your own DBMS implementation and Platform implementation, and the code generated by forsuredbcompiler would still work.

Why "anti-ORM?"

ORMs are Object Relational Mappings. In other words one or more objects will get created upon querying the database for each record of a relation that you use. Especially when you only want to access one or two fields of each record, it can be wasteful to serialize/deserialize a full object.

Additionally, ORMs are pretty tightly coupled to the representation of the objects as records in tables. In order to get around this limitation, the FSDocStoreGetApi was developed such that the database have both the features of a relational database and a document store. Because of this, you can mix/match document store and relational database features, choosing the API based upon the data that you want and how you access it.