Is HibernateD dead?
bauss
jj_1337 at live.dk
Fri May 4 07:18:09 UTC 2018
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.
More information about the Digitalmars-d-learn
mailing list