Is HibernateD dead?

[bauss]

On Thursday, 3 May 2018 at 23:05:02 UTC, Matthias Klumpp wrote:
> On Thursday, 3 May 2018 at 21:28:18 UTC, bauss wrote:
>> On Thursday, 3 May 2018 at 18:01:07 UTC, Matthias Klumpp wrote:
>>> DiamondMVC looks nice, but I would need PostgreSQL support 
>>> for sure.
>>> Therefore, I think there are three options:
>>>  1) Extend the DiamondMVC ORM to support missing features 
>>> that Hibernated has (maybe make it use ddbc as backend?)
>>>  2) Revive Hibernated - contacting Vadim Lopatin would be key 
>>> for that, and maybe the project could be maintained in the 
>>> dlang-community organization (although there are competing 
>>> projects for it...)
>>>  3) Find a different D ORM that does the job and expand it to 
>>> include missing features.
>>
>> Yes, I completely agree with PostgreSQL support. It's really 
>> important to me getting that working, as well MSSQL. I was 
>> hoping I could find time this weekend to actually do that.
>
> 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.

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

>
> [1]: https://github.com/buggins/ddbc
>
>> Perhaps I will end up having another "optional" dependency to 
>> it as a temporary until I can have a better implementation or 
>> something.
>>
>> 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.

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:

@DbProxy(functionName) string field;

...

auto functionName(RawDbType type)
{
     return the new datatype that matches the field with the 
@DbProxy attribute.
}

>  * 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.

> (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.

> 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.