HibernateD and DDBC - ORM and DB abstraction layer for D

[Vadim Lopatin]

On Thursday, 4 April 2013 at 09:01:16 UTC, Jacob Carlborg wrote:
> Is the attributes necessary at all? I would just go with:
>
> class User
> {
>     long id; // always assume auto increment, primary key, not 
> null and so on
>     string name;
>     Customer customer; // infer @ManyToOne
>     @ManyToMany LazyCollection!Role roles; // I guess this 
> cannot be inferred
>     LazyCollection!Foo foos; // infer @OneToMany
> }
>
> Perhaps for primitive types you could have:
>
> class User
> {
>     Long id;
>     String name;
>     Int foo;
> }
>
> Note the capital letters.

In Hibernate, there are two modes of automatic extraction of 
properties from clas: all fields or all getters/setters. Unless 
field or getter has no @Transient annotation, it's considered as 
property.
I can implement similar behavior.

If class doesn't have class level annotations, we can treat it as 
@Entity.
But in this case it's impossible to find entity classes in 
modules. Currently, HibernateD accept list of classes and/or 
modules, to extract metadata from.
If module is passed, how would we determine if some particular 
class in module is persistent or not? Either we have to import 
ALL classes of module as entities or only annotated.

Having default @ManyToOne for object field and @OneToMany for 
array of objects is a good idea.

It will be nice to define aliases like alias Nullable!long Long;

The question is how to determine what members of class to treat 
as properties?
Currently field, getter/setter pair, and @property supported. 
What should be rule to choose which of them import as fields?
Have a priority of @property access functions and getters/setters 
over usual fields? Ignore private and protected members?

BTW, having getField()/setField() looks like not a D way 
(@property should be used instead). Probably, I just can remove 
getters/setters support.