nsanch / meadow Goto Github PK

Meadow is a first draft of a scala ORM. I am not convinced its possible to make
an ORM that is actively good, so where possible I have tried to cut features
out.

Meadow is definitely inspired by Lift's Record and Field, both as a pattern and
as an anti-pattern. It borrows from lift, hopefully without replicating its
flaws.

*ValueContainer*: One of the biggest frustrations with Lift's Field/Record
classes is the sheer number of classes involved in its inheritance hierarchy.
It is incredibly difficult to figure out what types are accepted by various
methods or returned by them, let alone what the implementations of those
methods are. To address that problem, Meadow only has one concrete
ValueContainer class, and any additions in functionality are added either
through a Serializer or a custom Extension.

*Serializers* are responsible for mapping between the BSONObject's
that mongo provides and the logical types we actually want to program against.
It's trivial to support a new logical type by adding a new Serializer, usually
with <10 lines of code.

*Extensions* allow the addition of type-safe functionality to a ValueContainer
through composition, not inheritance. For example, the FKExtension provided
here allows for some fields to be marked as a foreign key to another
collection, and to have logic for looking up the referenced object. Extension's
are also given a pointer to the associated ValueContainer at construction-time
and have a callback that's triggered when the value of a field changes, so they
have a great deal of flexibility.

*Schemas* allow the declaration of an individual collection as a group of
fields. This is very much inspired by the MetaRecord idea in Lift, but there is
no inheritance relationship between the singleton Schema and the individual
Record.

*Records* are created to model an individual record in a database. Each record
contains a set of ValueContainer's and has a reference back to the Schema with
which it's associated.


Note:

- It is annoying that every field must be declared in its Schema and in its
   Record. I don't know of a way to fix without adding an undesired inheritance
   relationship or code-gen. Given those two alternatives, I think the
   inconvenience of the extra line in each Record isn't too bad.
- It is difficult to have traits shared across multiple Records.
- There is no relationship between a ValueContainer and the field that owns it,
   so you can't do x.foo(1).bar(2) like you can in lift.
- There is no .toForm or .validate functionality. Display logic and model logic
   do not belong together so explicitly, but it would be possible to make an
   Extension to add that functionality if desired.
- Meadow is relatively strict about failures, so it throws an exception if it
   can't parse a value in the DB, for example.