Is HibernateD dead?

[Matthias Klumpp]

I've written an email to Vadim, maybe we get a reply on the 
status of both projects.


On Friday, 4 May 2018 at 07:18:09 UTC, bauss wrote:
> [...]
>> Would it maybe be easier for you to base on ddbc[1] or another 
>> existing abstraction layer for database abstraction?
>> Ddbc is pretty neat, and even has support for reading structs 
>> directly from the database.
>>
>
> Perhaps, but it'd have to be a forked version as I don't really 
> want to depend on something that isn't updated regularly.
>
> ddbc's last commit was a year ago.

Yes, at the moment using ddbc and relying on it would mean taking 
over some maintenance of it. Ddbc is fairly complete though and 
might save you a lot of work, because it already abstracts a lot 
of (relational) database systems.

> I can't seem to find a license for it though?

It's Boost licensed (BSL-1.0), but probably needs an explicit 
LICENSE file.
Maybe we can move ddbc to dlang-community, so more people can 
easily commit changes to it (provided it gets accepted there, and 
Vadim agrees with that move as well).

>>> Perhaps I will end up having another "optional" dependency to 
>>> it as a temporary until I can have a better implementation or 
>>> something.

Taking over maintenance of it might be easier than reimplementing 
the database abstraction again though.
For Postgres, ddbc worked really well for me, and I assume its 
SQLite, MySQL and ODBC drivers are also still working well, 
meaning less work for you.
Without ddbc, you'd have to write new abstraction on top of some 
other libraries, like dpq2.

>>> The frontend part of postgresql is almost finished, it's just 
>>> having the postgresql driver working properly, which is where 
>>> it's frozen right now.
>>
>> Hmm... Does any public code for that exist already that I 
>> could play around with?
>> Unfortunately, I have a few more unusual requirements for 
>> Postgres, like:
>>  * UUIDs as primary keys, instead of integers
>
> As far as I remember the implementation of @DbId in Diamond, 
> then it supports whatever type.

Native support for std.uuid.UUID would be neat :-) For Hibernated 
I use a mixin to convert a UUID into strings transparently, for 
database insertion.

> Diamond doesn't care much about what type your primary key is.
>
> I will make sure that's how it function of course, if it 
> currently doesn't behave like it, but I'm pretty sure it does.
>
>>  * Ability to register custom datatypes with the ORM (version 
>> numbers in this case, the ORM can view them as text, but the 
>> database has a special type for them)
>
> That could be done with some attribute that lets you handle 
> columns yourself.
>
> Do you have a good name for it?
>
> I was thinking @DbProxy and then the function would be 
> something like:
> [...]

Registering a new type with Postgres yields a new OID to identify 
the type, so I would need a function to tell the Postgres backend 
to treat OIDs of a certain number like "text" types. Ideally, I 
would also need to annotate entity to set a specific column type, 
like:

```
class Entity {
     UUID uuid;

     @ColumType("versionnumber")
     string _version;
}
```
(With the result of CREATE TABLE not setting a "text" type for 
the new version column, but a "versionnumber" type instead)

That would do it. For Hibernated, I have Hibernated create the 
table initially, and then fire an ALTER TABLE at it afterwards to 
change the column type, while at the same time registering the 
new type OID with ddbc to be treated as text.
As said, this is a very specific requirement very few people will 
have ^^

Much more frequently people will ask for JSONB and JSON type 
support for a postgres driver though, I guess. For that, 
specifying the column type explicitly could be quite helpful as 
well, so switch between JSONB and JSON.

>>  * Obviously the usual ORM stuff, one-to-many, many-to-many, 
>> etc. relations
>>
>
> Yes, relations is one thing I haven't added and I have been 
> wanting to do it for a while.
>
> I will definitely look into having it added as well.

That's kind of key for an ORM :-) Handling relations manually was 
what made me abandon my "I just write raw SQL for everything" 
ways, because it gets quite complex and annoying in the long run.

>> (Obviously not a must-have list, I added support for custom 
>> datatypes to my ddbc fork as well, because it's not really a 
>> feature many people need)
>
> Well, that's kind of the key to most of the development in 
> Diamond.
>
> I usually add functionality that isn't widely used and in most 
> cases people implement it themselves ex. the whole diamond.seo 
> is not usually something a framework has.

I keep an eye on it - at the moment, Vibe.d satisfies all 
requirements I have on a web framework, but that might change.
A well integrated ORM would certainly be a game changer, since 
Vibe.d is limited to Mongo and Redis only.

>> Diamond is a neat project, I played around with it about half 
>> a year ago, but didn't test the ORM part at all back then.
>
> It wasn't that good back then and has improved a lot since, as 
> well many other parts of Diamond. Over the past half year it 
> has grown rapidly, both in stability and functionality.

It's quite an impressive piece of work, especially since it looks 
like you're the only one working on it.
Keep it up! :-)