Okay so next milestone in Dvorm's[0] development has been meet.
Because of this being technically the first announced release I'll cover most of it here.

Dvorm is designed to be an ORM heterogeneous of the database provider itself. I've proven this by using email and MongoDB as providers. This unfortunately means some things are rather inefficient. I.e. you cannot get the type of the data model in the provider. Now some form of CTFE registration of providers would fix that (I really need this for Cmsed as well to remove devs having to register e.g. routes and data models).

The usual expected functions on a data model include:
* static T findOne(U... args)
* static T[] findAll
* static T[] find(U... args)
* void save
* void remove
* static @property Query!T query

Note query, this is important for much more advanced filtering of records.
For some providers e.g. Mongo this would be executed on the server. In others like memory or email, it'll get executed in D.

For every property (with respect to e.g. @dbIgnore) it'll generate the above code and as well a bunch of functions in the query e.g. isbn_eq for checking if value is equal to given value.

Now a query supports a few functions itself. I.e. count, find and remove.

There is currently a couple of restrictions. For instance you cannot put an object with ids being non primitives/string. My current recommendation is to have a struct dedicated towards being the id of a data model. This also gives the benefit of using this in others for referencing.

There is relationship support in the form of @dbActualModel!(T, propertyOnT).
This is mostly used for logging in Dvorm. In e.g. Cmsed it alters codegen for javascript version of models.
However using e.g. opAssign in an id of a data model you can "fake" setting of this.

As an example from Cmsed's test data models (Cmsed automatically logs by using Dvorm's built in logging mechanism):

Books3:
PK: [string] _id
[ubyte] edition = 0
[string] something
=======----=======
Page3:
PK: [string] _id
FK: [Books3][string] book_id


Changes in this version boils down to:
* Added struct support
* Added email (pop3/smtp) provider

Currently Dvorm is very limited to non numeric indexed only or only numeric index database providers per model. Next milestone will fix this by moving the control of the unique key to Dvorm. This will pave the way for OpenDBX support which will include Mysql.

I want to work heavily towards supporting database migrations of data. I believe this to be one of dvorm's targets in the future. Because how easy it is to change between database providers or just databases.

I'm not yet working on documentation. I want to get a really good web site up which covers both Cmsed and Dvorm when they are both ready for it (quite a way away).
This to me is an important issue that will have to be dealt with to show how powerful these libraries are. ApplyYourDLang[1] will go a long way to doing this (youtube channel).

[0] https://github.com/rikkimax/Dvorm
[1] https://www.youtube.com/channel/UCz3NlrGpjV9NlJAhKJLu_-w

This is great! Can't wait to check it out. (^_-)b