The Painless High‑Level Persistence Engine
PHiLe (pronounced fillet), the Painless High‑Level Persistence Engine, is a next‑generation database management tool and domain‑specific language. It allows application developers to write what is basically a textual form of a conceptual or entity relationship model, from which it automatically generates a Database Abstraction Layer.
Unlike traditional ORMs, it has a strong, expressive type system. It allows programmers to work with many kinds of values, not only objects, therefore trivially eliminating many of the bottlenecks commonly associated with ORM solutions, such as having to retrieve the transitive closure of an object, only to discard all but a few of its scalar attributes.
PHiLe also supports a wide spectrum of different languages and databases, therefore it cooperates well with many already-existing technology stacks. It includes tools for automatically migrating data of the same conceptual schema between different underlying database engines, and another DSL for refactoring the schema without loss of data or type safety.
Sure! Depending on how you are willing to use PHiLe, you may be looking for…
The philosophy behind the design of PHiLe is explained in detail on my blog.
The PHiLe DSL is a statically‑typed, object-oriented, functional-declarative language, which is capable of describing schemas (like a DDL) and queries/updates (like a DML). It brings the memory model that programmers are familiar with to the world of persistent storage: relational tables become classes or structs, records and documents become objects, and relationships become arrays and pointers.
As rightfully expected from a modern functional language, the PHiLe DSL supports advanced and convenient features such as higher‑order functions, pattern matching, and algebraic data types (including class, struct, tuple, enum and optional types). Enums, in particular, are a type‑safe alternative to stringly‑typed fields, while proper optional types prevent errors related to NULL values.
PHiLe will support the following database flavors and programming languages:
Support for other popular storage engines (e.g. Postgres, MS/SQL, Redis, …) and programming languages (e.g. Haskell, Ruby, C#, …) would be nice and is planned.