tabel was made out of the need felt for a simple Object-Relational-Mapper for PostgreSQL.
Its salient features are:
- A query scoping mechanism that is “join-aware”. That is, you can declare query scopes which apply table-joins only once, no matter how many times they are called while forming the final query. This might seem like a small feature, but it saves a lot of headaches in application code where you need to apply joins and where clauses according to some input parameter. This “join-aware-query-scoping-mechanism” is also used internally by tabel to power a very powerful feature called relationship joins.
- Complete separation of persistence and domain logic. When using tabel, you do not stuff your domain logic into table-definitions. Your domain logic can exist in a separate module, which uses tabel ORM for persistence. No need to think twice about “proper-software-design” when you find yourself using more than one data-store. tabel makes your relational database act as just another data-store.
tabel is implemented as a thin layer over the really awesome knex.js query builder. This layer allows you to define table-gateways which can eager-load and manage relations, while giving you the ability to drop down to knex, or raw sql when you need to. This way, tabel helps you with rapid development by providing relation management and helping you define a domain-query-language, and steps out of your way when you need to take control of your database.
Another big difference is that when using tabel to build an application, you won’t find yourself defining model methods. You will define various tables for the
orm object, which you create one of per database, and then use the orm object read and mutate data in the database. This way instead of building a model-layer, you build a set of functions for various parts of your domain logic, which then cleanly come together to form a domain-specific-language for tackling the problem you are trying to solve with the software you are making.