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?
