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
