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.

On Wed, 03 Apr 2013 16:28:36 +0200
"Vadim Lopatin" <coolreader.org@gmail.com> 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.
> 

Sounds cool.

Can it be used with Vibe.d's system of asynchronous
connections? If not, then perhaps a backend for mysql-native
<https://github.com/rejectedsoftware/mysql-native/> could be added?

> Sounds cool.
>
> Can it be used with Vibe.d's system of asynchronous
> connections? If not, then perhaps a backend for mysql-native
> <https://github.com/rejectedsoftware/mysql-native/> could be added?

Actually I'm using mysqln as backend. But I patched it, removing vibe dependancies. (Vibe connection replaced with standard one).

On Wed, 03 Apr 2013 18:54:13 +0200
"Vadim Lopatin" <coolreader.org@gmail.com> wrote:

> > Sounds cool.
> >
> > Can it be used with Vibe.d's system of asynchronous connections? If not, then perhaps a backend for mysql-native <https://github.com/rejectedsoftware/mysql-native/> could be added?
> 
> Actually I'm using mysqln as backend. But I patched it, removing vibe dependancies. (Vibe connection replaced with standard one).

Ahh, ok. In that case, I may diff the two and see about making "vibe.d connections vs std connections" a configurable choice (with vibe.d dependency disableable via -version switch). Then perhaps HibernateD/DDBC users and direct mysql-native users can both benefit from whichever form they need. Plus that way you wouldn't need to be bothered with keeping a separate fork of mysqln in sync.

On Wednesday, 3 April 2013 at 17:22:46 UTC, Nick Sabalausky wrote:
>> Actually I'm using mysqln as backend. But I patched it, removing vibe dependancies. (Vibe connection replaced with standard one).
>
> Ahh, ok. In that case, I may diff the two and see about making "vibe.d
> connections vs std connections" a configurable choice (with vibe.d
> dependency disableable via -version switch). Then perhaps
> HibernateD/DDBC users and direct mysql-native users can both benefit
> from whichever form they need. Plus that way you wouldn't need to be
> bothered with keeping a separate fork of mysqln in sync.

It would be the best solution, to include patch into upstream, and use upstream mysqln in DDBC.

Besides connection replacement, I've added some getters to retrieve resultset and parameters metadata from mysqln, to support NULL blobs, and some more fixes.

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.

-- 
/Jacob Carlborg

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?

I don't see what to simplify in markup like this:

    @Entity
    class User {

        @Generated
        long id;

        @Column
        string name;

        @ManyToOne
        Customer customer;

        @ManyToMany
        LazyCollection!Role roles;
    }

Which translates to table definitions like
CREATE TABLE user (id bigint not null primary key auto_increment, name varchar(255), customer_fk bigint foreign key references customer(id));
CREATE TABLE user_roles (user_fk bigint not null foreign key references user(id), role_fk int not null foreign key references role(id), primary key(user_fk, role_fk);
...

On Wednesday, 3 April 2013 at 17:22:46 UTC, Nick Sabalausky wrote:
> On Wed, 03 Apr 2013 18:54:13 +0200
> "Vadim Lopatin" <coolreader.org@gmail.com> wrote:
>
>> > Sounds cool.
>> >
>> > Can it be used with Vibe.d's system of asynchronous
>> > connections? If not, then perhaps a backend for mysql-native
>> > <https://github.com/rejectedsoftware/mysql-native/> could be added?
>> 
>> Actually I'm using mysqln as backend. But I patched it, removing vibe dependancies. (Vibe connection replaced with standard one).
>
> Ahh, ok. In that case, I may diff the two and see about making "vibe.d
> connections vs std connections" a configurable choice (with vibe.d
> dependency disableable via -version switch). Then perhaps
> HibernateD/DDBC users and direct mysql-native users can both benefit
> from whichever form they need. Plus that way you wouldn't need to be
> bothered with keeping a separate fork of mysqln in sync.

:-S The better way would be to just depend on a Stream interface
and switch implementations by instantiating different classes. -> The used Stream interface would of course need to be factored out of vibe, ideally into the standard library.

This would be way more flexible: Users of the library can use either implementation without even having to recompile the library. No additional runtime cost either.

"-version" should not be used too liberally in my opinion, because it is really inflexible, especially when it comes to binary/shared libraries.


Best regards,

Robert

On 2013-04-03 21:07, Vadim Lopatin wrote:
> I don't see what to simplify in markup like this:
>
>      @Entity
>      class User {
>
>          @Generated
>          long id;
>
>          @Column
>          string name;
>
>          @ManyToOne
>          Customer customer;
>
>          @ManyToMany
>          LazyCollection!Role roles;
>      }
>
> Which translates to table definitions like
> CREATE TABLE user (id bigint not null primary key auto_increment, name
> varchar(255), customer_fk bigint foreign key references customer(id));
> CREATE TABLE user_roles (user_fk bigint not null foreign key references
> user(id), role_fk int not null foreign key references role(id), primary
> key(user_fk, role_fk);
> ...

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.

-- 
/Jacob Carlborg