Okay so next milestone in Dvorm's 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
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
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,
This is mostly used for logging in Dvorm. In e.g. Cmsed it alters
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):
PK: [string] _id
[ubyte] edition = 0
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
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
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 will
go a long way to doing this (youtube channel).