Is HibernateD dead?

[Timoses]

On Thursday, 3 May 2018 at 10:27:47 UTC, Pasqui23 wrote:
> Last commit on https://github.com/buggins/hibernated
> was almost a year ago
>
> So what is the status of HibernateD?Should I use it if I need 
> an ORM? Or would I risk unpatched security risks?

Okay... wall of text.
TLDR: project definition / future of HibernateD?; prospects of an 
OGM layer integration (personally interested in Neo4j)?


I've been thinking of trying to implement an OGM (Object-graph 
mapping; i.e. NoSQL) for Neo4j in D as I'd love using it for a 
project of mine. The question is, whether it should be a separate 
project or whether something like this could be integrated with 
HibernateD.

I've taken a look at Hibernate ORM and OGM. There OGM is a 
separate project leveraging a lot of ORMs capabilities.

I'm still in the process of diving deeper into Hibernate's 
ORM/OGM documentation(/implementation) to get an idea of how it 
all works. I'm not particularly experienced with it.

One question that arises in respect to HibernateD is:
What is the purpose of HibernateD? The README states "HibernateD 
is ORM for D language (similar to Hibernate)". I guess there are 
two Extremes:

A. Replicate the structure of Hibernate into D, in a way porting 
it 1:1,

B. Implement an ORM from scratch.

Both approaches would be impractical for the following reasons:

contra A. An exact replica would leave no room for optimizations 
or creating a more D-idiomatic library,

contra B. Creating a completely new solution and interface would 
miss out on leveraging what Hibernate already "knows". Further, 
Hibernate users might love seeing a familiar interface they can 
work with. Option B wouldn't deserve the name "HibernateD"..

This solely highlights that the project's purpose/description 
might need some more explanation.

A small look into the code reveals that the approach leans 
towards implementing the component structure of Hibernate (such 
as dialects, a Hibernate(D) basic type system, ...).

I'd guess this would be the most practical approach:

Leverage Hibernate's insights into what components are required 
to implement an ORM(/OGM) (Dialects, Hibernate(D) types, 
annotations, Persistence Strategies, ...) and find D-idiomatic 
ways for implementation. Any space for optimization should 
naturally be capitalized on.

A complete 1:1 replica does not seem practical as for example 
I've stumbled across the "@Immutable" annotation in the Hibernate 
documentation. As there is the "immutable" qualifier in D, 
through introspection, this quality could be deduced from 
entities/members. This leads to thinking that solutions tailored 
towards D need to be found and therefore deviation from Hibernate 
sounds reasonable.


I am in no way an expert in ORMs (I just started reading 
Hibernate's ORM documentation) and I have no idea what other ORMs 
are out there (D or non-D). However, Hibernate seems quite 
popular (and it offers a Neo4j OGM interface) and the fact that 
it exists for D (at least in a "starting positition") caught my 
attention.

What do you think? Especially bauss, Matthias and singingbush, as 
you seem motivated to move the project forward. Maybe Vadim also 
has a standpoint : ).