HibernateD and DDBC - ORM and DB abstraction layer for D

[Vadim Lopatin]

On Wednesday, 3 April 2013 at 18:36:16 UTC, Jacob Carlborg wrote:
> On 2013-04-03 16:28, Vadim Lopatin wrote:
>> Hello!
>>
>> I've started implemetation of ORM in D, with annotations and 
>> interfaces
>> similar to Hibernate.
>>
>> As DB abstraction layer I wrote DDBC - library with interface 
>> similar to
>> JDBC. Only MySQL driver is implemented. PostgreSQL - in 
>> progress.
>>
>> Project is hosted on SourceForge:
>> https://sourceforge.net/p/hibernated/wiki/HibernateD/ License 
>> is Boost
>>
>> HibernateD collects metadata from classes annotated with 
>> Hibernate-like
>> UDAs.
>>
>> Simple properties of supported: you can annotate fields, D 
>> properties or
>> getter+setter pairs in your class, of types string, byte, 
>> short, int,
>> long, ubyte, ushort, uint, ulong, byte[], ubyte[], DateTime, 
>> Date,
>> TimeOfDay; for non-nullable types to support Null value use 
>> Nullable!
>> template.
>>
>> @Embedded entities supported - you can embed properties from 
>> @Embeddable
>> object to @Entity's table.
>>
>> @OneToOne, @OneToMany, @ManyToOne, @ManyToMany relations are 
>> supported.
>> You can use Lazy! and LazyCollection! to support lazy loading 
>> of
>> aggregates.
>>
>> You can query DB using subset of HQL (Hibernate Query 
>> Language).
>>
>> Look at project wiki and unittests for more info.
>
> Seems to be fairly complex API. How about using some 
> convention-over-configuration.

I believe HibernateD follows convention-over-configuration 
principles.

As per Wikipedia article for convention-over-configuration, "The 
phrase essentially means a developer only needs to specify 
unconventional aspects of the application. For example, if 
there's a class Sale in the model, the corresponding table in the 
database is called “sales” by default. It is only if one deviates 
from this convention, such as calling the table “products_sold”, 
that one needs to write code regarding these names."

At least, for most annotations in HibernateD, you don't need to 
specify parameters like table or columns names, their types, 
nullability, etc.
By default, they are being generated automatically in reasonable 
way.
Say, for "@Entity class CustomerInfo {}" table name 
"customer_info" will be used. For field "@Column int 
streetAddress;", column name "street_address" NOT NULL will be 
used. "@Column Nullable!long flags;" will be NULL in DB.

Unlike Hibernate, in HibernateD there is on option to treat all 
fields/properties/getters as entity properties automatically, 
even if not annotated. In HibernateD, at least @Column annotation 
should present. Not sure it's a big problem.

Where could convention-over-configuration be used in ORM API 
besides annotations?