• Rikki Cattermole (67/67) Feb 18 2014 Okay so next milestone in Dvorm's[0] development has been meet.
• Jonathan Dunlap (1/1) Feb 21 2014 This is great! Can't wait to check it out. (^_-)b

"Rikki Cattermole" <alphaglosined gmail.com> writes:

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

"Jonathan Dunlap" <jadit2 gmail.com> writes:

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