Skip to content
This repository has been archived by the owner on May 1, 2020. It is now read-only.

Defining table schemas

Jump to bottom
Sam Bosley edited this page Jun 18, 2015 · 8 revisions

Table schemas are represented in SquiDB with subclasses of TableModel. While it is possible to write TableModel subclasses by hand, nearly always you will want to use the SquiDB code generator. TableModel subclasses tend to be a bit verbose and repetitive, so SquiDB includes a code generation tool that will write your TableModel subclasses for you using compile-time annotation processing. This enables developers to define their table schemas in much simpler Java classes, which we refer to as "Model specs" after the annotations used to mark them for processing by the code generator.

Here's an example of a model spec class:

@TableModelSpec(className="Person", tableName="people")
public class PersonSpec {

    public String firstName;

    public String lastName;

    public int age;

}

This corresponds to a schema for a table named "people". The table will be represented by a subclass of TableModel named "Person" and have four columns: an automatically generated primary key column named "_id", a text column named "firstName", a text column named "lastName", and a numeric column named "age".

The supported types you can use to declare columns are:

  • any Java primitive or any boxed version thereof (int/Integer, boolean/Boolean, etc.)
  • String
  • byte[] (for blobs)

Custom primary key definitions

By default, SquiDB will generate a LongProperty defining the primary key column for the table named "_id". If you are using SquiDB with a legacy database that has a different name for the primary key column or if you just want to give your id column a different name, you can use the @PrimaryKey annotation:

@TableModelSpec(className="Person", tableName="people")
public class PersonSpec {

    @PrimaryKey
    long myId;

    ....
}

The above example would have a column "myId" as the integer primary key, with a LongProperty MY_ID in the generated model class. By default, primary keys will use the AUTOINCREMENT behavior, but this can be disabled with a parameter in the @PrimaryKey annotation.

At this time, SquiDB only supports tables with a single INTEGER PRIMARY KEY column. This may change in a future release.

SquiDB is not an ORM

In SquiDB, all model entities/table schemas are defined separately, not relationally. In other words, you can't define a model where one property is a list of other models:

@TableModelSpec(className="Person", tableName="people")
public class PersonSpec {
    String name;
    // This is not allowed
    List<Book> books;
}

This is by design. We've found that ORMs that attempt to manage relationships by hiding the underlying SQL for you tend to be difficult to reason about or have unpredictable performance characteristics. Because of this, SquiDB focuses on making it easy to work with SQL, rather than trying to hide SQL from you. This also leaves you free to implement any relationship management strategy you want, rather than forcing one on you. You could manage relationships through utility classes and helper functions, foreign key constraints, ModelMethods with transitory values for caching, or some other strategy--perhaps even a combination of these ideas. The choice is yours!

See also:

Clone this wiki locally