HibernateD and DDBC - ORM and DB abstraction layer for D

[Vadim Lopatin]

On Thursday, 4 April 2013 at 09:54:48 UTC, Dicebot wrote:
> On Wednesday, 3 April 2013 at 19:07:39 UTC, Vadim Lopatin wrote:
>> I don't see what to simplify in markup like this:
>> ...
>
> You may implement approach similar to one used in vibe.d 
> http.rest and http.form modules. Some specific examples are 
> described by Jacob, but, in general, in results in 3 
> configuration stages:
> 0) No configuration at all, all data is inferred from variable 
> names and types according to some sane convention.
> 1) Convention configuration - you chose one convention to use 
> for aggregate type introspection at compile-time. Few different 
> pre-defined conventions exist.
> 2) Fine configuration using UDAs.


Implemented changes for better convention-over-configuration:
- If no annotations on class level, @Entity is assumed.
- No required annotation for simple properties. Nullability is 
deduced from data type
- @Embedded annotation is not needed anymore - it's deduced from 
field's class @Embeddable annotation
- If no key field annotations specified in class (@Id, 
@Generated, @Generator) - property named "id" (if any) is 
considered to be a @Generated primary key.
- For Object fields @ManyToOne is applied by default
- For Object[] or LazyCollection!Object @OneToMany is applied by 
default
- @OneToOne and @ManyToOne are required, since cannot be deduced

Following declarations are valid (comments describe ):

// @Entity assumed since no @Embeddable annotation
class User {
    long id;         // @Generated deduced from field name
    string name;     // deduced @NotNull
    Address address; // deduced @Embedded from annotation of 
Address
    Customer customer; // deduced @ManyToOne @JoinColumn
    // annotation required, otherwise would be deduced as 
@OneToMany
    @ManyToMany Roles[] roles;
}

@Embeddable // required for Embeddable
class Address {
    String zip;           // @Null
    String state;         // @Null
    string streetAddress; // @NotNull
}

// @Entity assumed since no @Embeddable annotation
class Customer {
    int id;     // @Generated primary key - from field name
    string name;// @NotNull
    Long flags; // @Null - because it's Long - not long
    LazyCollection!User users; // @OneToMany by default
    // annotation required, otherwise would be deduced as 
@ManyToOne
    // @JoinColumn is required on one of OneToOne sides
    @OneToOne @JoinColumn CustomerOptions customerOptions;
}

// @Entity assumed
class CustomerOptions {
    int id;
    // annotation required, otherwise would be deduced as 
@ManyToOne
    @OneToOne Customer customer;
}

// @Entity assumed since no @Embeddable annotation
class Role {
    int id;      // @Generated
    string name; // @NotNull
    // annotation required, otherwise would be deduced as 
@OneToMany
    @ManyToMany LazyCollection!User users;
}

Aliases added, to simple put uppercase Long instead of 
Nullable!long in code:
alias Nullable!byte Byte;
alias Nullable!ubyte Ubyte;
alias Nullable!short Short;
alias Nullable!ushort Ushort;
alias Nullable!int Int;
alias Nullable!uint Uint;
alias Nullable!long Long;
alias Nullable!ulong Ulong;
alias Nullable!float Float;
alias Nullable!double Double;
alias Nullable!DateTime NullableDateTime;
alias Nullable!Date NullableDate;
alias Nullable!TimeOfDay NullableTimeOfDay;

String (uppercase nullable version of string) is defined as 
struct wrapper around string field, with interface similar to 
Nullable!
Looks ugly, but I tried `typedef string String`, but it is 
deprecated; `alias string String` cannot be distinguished from 
just string. How to define String better? Is there a good way to 
define String to be compatible with string, but with the ability 
to distinguish between string and String in compile time?