Proposal: Database Engine for D

Jacob Carlborg via Digitalmars-d digitalmars-d at puremagic.com
Sun Jan 3 23:48:14 PST 2016


On 2016-01-03 17:45, Sebastiaan Koppe wrote:

> Suppose you have this:
>
> mixin(db(`
> Entity Person
>    Fields
>      name -> string
>      age -> integer
>    Query
>      byAge(a -> integer) -> age == a
> `));
>
> which generates something like this:
>
> struct Person
> {
>    string name;
>    int age
> }
> auto getPersonByAge(DB db, int a)
> {
>    return db.prepare!Person("SELECT name,age FROM Person WHERE age =
> ?").query(a);
> }
>
> and then later in time:
>
> mixin(db(`
> Entity Person
>    Fields
>      name -> string
>      age -> integer
>      phone -> string
>    Query
>      byAge(a -> integer) -> age == a
> `));
>
> Given that you have access to both version it is easy to generate
> migration code for the phone field.
>
> Maybe it is contrived, but I think it shows you can do more with the DSL
> than just validating queries.

Perhaps I'm missing something obvious but there are several problems 
with this:

1. What happens when you use more than one query for the same table at 
the same scope? In the above case, "Person" is already defined the 
second time "db" is invoked. It's not possible to add fields for already 
declared structs. Unless you use some form of opDispatch backed by an 
associative array of variants

2. What happens if I want to execute a custom query in a function, i.e. 
a query that is only used once. Will it generate the sturct inside the 
function or am I forced to always use this mixin at module level?

I still think it's a lot easier to declare the struct with standard D 
code. I don't think the DSL adds any value in this case. Just do 
something like:

@db struct Person
{
     string name;
     int age;
}

The @db attribute would allow to create the migrations.

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list