HibernateD and DDBC - ORM and DB abstraction layer for D

[Jacob Carlborg]

On 2013-04-05 09:32, Vadim Lopatin wrote:

> 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;
> }

> 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?

Why won't Nullable!(string) String work?

Looks much better know. I'm wondering though, if there need to be a way 
to indicate a regular instance variable that isn't a column.

-- 
/Jacob Carlborg