HibernateD and DDBC - ORM and DB abstraction layer for D
coolreader.org at gmail.com
Thu Apr 4 03:02:29 PDT 2013
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
I can implement similar behavior.
If class doesn't have class level annotations, we can treat it as
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
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
More information about the Digitalmars-d-announce