www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Is HibernateD dead?

reply Pasqui23 <p example.com> writes:
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?
May 03 2018
next sibling parent reply bauss <jj_1337 live.dk> writes:
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?


Although currently only mysql/mariadb support, then you can 
easily implement your own, but there is an orm in Diamond:

Basically you can strip out whole "diamond.data" and 
"diamond.database", I'm pretty sure they don't really depend on 
anything except for maybe one or two modules in "diamond.core"

http://diamondmvc.org/docs/data/#database

I'm planning on making a more light-weight version of the ORM 
that makes it even easier to implement your own, as right now 
you'd need to understand the mechanics of it, "kinda"

I'm currently working on having some more support for other 
database drivers, but my time is very limited at the moment, 
hence why even postgresql support has been frozen for a while 
(Also due to the fact that I can't use the vibe.d postgresql 
package as it doesn't work with Windows, so I need to make my own 
implementation and I simply haven't had time.)

I'll be more than happy to assist you in implementing it for 
whatever target you have, either create an issue in the 
repository: https://github.com/DiamondMVC/Diamond/issues or write 
a mail to contact diamondmvc.org
May 03 2018
parent bauss <jj_1337 live.dk> writes:
On Thursday, 3 May 2018 at 11:00:36 UTC, bauss wrote:

 On Thursday, 3 May 2018 at 10:27:47 UTC, Pasqui23 wrote:




That is if you want to use something that isn't "dead"



 May 03 2018



prev sibling next sibling parent reply Matthias Klumpp <matthias tenstral.net>  writes:


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?


Hah!
I was just browsing the forums thinking about the same issue and 
whether I should ask a question about it.
I am using Hibernated in one bigger project, ripping it out at 
this point would be quite painful and I only ever want to do that 
if there is a sustainable and actively developed alternative that 
is comparable in features[1].

Truth is, so far I haven't found any D ORM that compares to 
Hibernated in terms of supported features and databases. 
Hibernated also has issues though, at the time I maintain a 
forked version with changes that I hope to upstream soon - 
unfortunately, the trivial open pull-request on the project 
doesn't look promising.

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.

I really don't want to write ORMs in D and I actually lack the 
skills to do it properly, but I rely pretty heavily on Hibernated 
and ddbc. So, if anyone has a solution for this, I would help 
with it for sure.
Asking Vadim (buggins) on the state of Hibernated would be the 
first thing to do, I think.

Cheers,
     Matthias

[1]: In fact, when I switched the database backend once in the 
past from an attempt to not use an ORM to using Hibernated, I was 
very close to rewriting the whole thing in Python - in D, there 
are tons of ORMs and database abstraction layers written, but not 
a single one compares even remotely to the likes of SQLAlchemy. 
It would be awesome if instead of 5 70% completed projects, we 
had one 90% complete one.



 May 03 2018



 next sibling parent reply bauss <jj_1337 live.dk>  writes:


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.

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.

MSSQL should be fairly easy, just wrapping odbc, which perhaps I 
could make a general odbc orm wrapper which could then be used 
for pretty much all alternatives.



 May 03 2018



  parent reply Matthias Klumpp <matthias tenstral.net>  writes:


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.


[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
  * 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)
  * Obviously the usual ORM stuff, one-to-many, many-to-many, etc. 
relations

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

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.



 May 03 2018



  parent reply bauss <jj_1337 live.dk>  writes:


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.



 May 04 2018



  parent reply Matthias Klumpp <matthias tenstral.net>  writes:


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! :-)



 May 04 2018



  parent  Bauss <jj_1337 live.dk>  writes:


On Friday, 4 May 2018 at 19:54:46 UTC, Matthias Klumpp wrote:

 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! :-)


Thanks for the license information. I wouldn't mind taking over 
maintenance of ddbc and you're right that it would definitely be 
much easier to integrate. Also it could be better to cut down 
different dependencies for each driver.

Let's see what we can figure out. I have a lot of this weekend so 
I'll try to throw in time for this.

And yes, I've been working as the only developer since I started 
two years ago, but sometimes it would be nice with more 
developers as development would be faster and it wouldn't die 
when I'm busy



 May 05 2018



prev sibling  parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com>  writes:


You should get a hold of Vadim Lopatin and see if he would give 
you commit rights to the main repo.

There was a great article I can't find by someone who would add 
contributors if they made good pull requests. It helped to keep 
his work living on and didn't need to keep involved.

So I push for people to follow this model (remove contributors if 
it isn't working out.



 May 07 2018



  parent reply Vadim Lopatin <coolreader.org gmail.com>  writes:


On Monday, 7 May 2018 at 17:27:17 UTC, Jesse Phillips wrote:

 You should get a hold of Vadim Lopatin and see if he would give 
 you commit rights to the main repo.

 There was a great article I can't find by someone who would add 
 contributors if they made good pull requests. It helped to keep 
 his work living on and didn't need to keep involved.

 So I push for people to follow this model (remove contributors 
 if it isn't working out.


Guys, if you want to get permissions for pushing to buggins/ddbc 
and buggins/hibernated, please send me you github id to 
coolreader.org gmail.com



 May 08 2018



  parent  bauss <jj_1337 live.dk>  writes:


On Tuesday, 8 May 2018 at 07:28:31 UTC, Vadim Lopatin wrote:

 On Monday, 7 May 2018 at 17:27:17 UTC, Jesse Phillips wrote:

 You should get a hold of Vadim Lopatin and see if he would 
 give you commit rights to the main repo.

 There was a great article I can't find by someone who would 
 add contributors if they made good pull requests. It helped to 
 keep his work living on and didn't need to keep involved.

 So I push for people to follow this model (remove contributors 
 if it isn't working out.


 Guys, if you want to get permissions for pushing to 
 buggins/ddbc and buggins/hibernated, please send me you github 
 id to coolreader.org gmail.com


I've just sent you a mail :)



 May 08 2018



prev sibling next sibling parent reply singingbush <singingbush hotmail.com>  writes:


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?


Both hibernated and ddbc have had open pull requests for months. 
It's really frustrating.



 May 03 2018



  parent reply Matthias Klumpp <matthias tenstral.net>  writes:


On Thursday, 3 May 2018 at 18:52:34 UTC, singingbush wrote:

 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?


 Both hibernated and ddbc have had open pull requests for 
 months. It's really frustrating.


Oh hey :-) I applied your patches for ddbc and hibernated a to my 
copy while back, because they weren't merged and fix real issues.
There are also other patches floating around, for example people 
will really want 
https://github.com/KrzaQ/hibernated/commit/efa38c50effdd77e973b
74feea89016b8d1fa1f applied when using hibernated.

If there is enough interest, we can maybe provide at least some 
basic level of maintenance for these projects together, maybe 
under the dlang-community umbrella or similar.
Per adoption guidelines[1], I think the projects are popular 
enough, but Hibernated is of course not the only D ORM (although 
a pretty complete one), and the continued maintenance is also not 
sure, even when PRs finally get reviewed and accepted faster (but 
that really depends on the library users).

In any case, we need to get in contact with buggins. I asked him 
ages ago about Hibernated on Gitter, but that was probably the 
worst way to contact him (as he is active on Github, but probably 
never read that message).


[1]: https://github.com/dlang-community/discussions



 May 03 2018



  parent reply Vadim Lopatin <coolreader.org gmail.com>  writes:


On Thursday, 3 May 2018 at 20:49:35 UTC, Matthias Klumpp wrote:

 On Thursday, 3 May 2018 at 18:52:34 UTC, singingbush wrote:

 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?


 Both hibernated and ddbc have had open pull requests for 
 months. It's really frustrating.


 Oh hey :-) I applied your patches for ddbc and hibernated a to 
 my copy while back, because they weren't merged and fix real 
 issues.
 There are also other patches floating around, for example 
 people will really want 
 https://github.com/KrzaQ/hibernated/commit/efa38c50effdd77e973b
74feea89016b8d1fa1f applied when using hibernated.

 If there is enough interest, we can maybe provide at least some 
 basic level of maintenance for these projects together, maybe 
 under the dlang-community umbrella or similar.
 Per adoption guidelines[1], I think the projects are popular 
 enough, but Hibernated is of course not the only D ORM 
 (although a pretty complete one), and the continued maintenance 
 is also not sure, even when PRs finally get reviewed and 
 accepted faster (but that really depends on the library users).

 In any case, we need to get in contact with buggins. I asked 
 him ages ago about Hibernated on Gitter, but that was probably 
 the worst way to contact him (as he is active on Github, but 
 probably never read that message).


 [1]: https://github.com/dlang-community/discussions


Guys,

If someone is ready to maintain these projects, I can grant 
privileges for github repositories ddbc, hibernated.

Best regards,
     Buggins



 May 06 2018



 next sibling parent reply bauss <jj_1337 live.dk>  writes:


On Monday, 7 May 2018 at 06:12:19 UTC, Vadim Lopatin wrote:

 On Thursday, 3 May 2018 at 20:49:35 UTC, Matthias Klumpp wrote:

 On Thursday, 3 May 2018 at 18:52:34 UTC, singingbush wrote:

 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?


 Both hibernated and ddbc have had open pull requests for 
 months. It's really frustrating.


 Oh hey :-) I applied your patches for ddbc and hibernated a to 
 my copy while back, because they weren't merged and fix real 
 issues.
 There are also other patches floating around, for example 
 people will really want 
 https://github.com/KrzaQ/hibernated/commit/efa38c50effdd77e973b
74feea89016b8d1fa1f applied when using hibernated.

 If there is enough interest, we can maybe provide at least 
 some basic level of maintenance for these projects together, 
 maybe under the dlang-community umbrella or similar.
 Per adoption guidelines[1], I think the projects are popular 
 enough, but Hibernated is of course not the only D ORM 
 (although a pretty complete one), and the continued 
 maintenance is also not sure, even when PRs finally get 
 reviewed and accepted faster (but that really depends on the 
 library users).

 In any case, we need to get in contact with buggins. I asked 
 him ages ago about Hibernated on Gitter, but that was probably 
 the worst way to contact him (as he is active on Github, but 
 probably never read that message).


 [1]: https://github.com/dlang-community/discussions


 Guys,

 If someone is ready to maintain these projects, I can grant 
 privileges for github repositories ddbc, hibernated.

 Best regards,
     Buggins


I wouldn't mind attempting maintaining them



 May 07 2018



  parent reply Matthias Klumpp <matthias tenstral.net>  writes:


On Monday, 7 May 2018 at 08:26:15 UTC, bauss wrote:

 On Monday, 7 May 2018 at 06:12:19 UTC, Vadim Lopatin wrote:

 On Thursday, 3 May 2018 at 20:49:35 UTC, Matthias Klumpp wrote:

 On Thursday, 3 May 2018 at 18:52:34 UTC, singingbush wrote:

 On Thursday, 3 May 2018 at 10:27:47 UTC, Pasqui23 wrote:

 [...]






 If someone is ready to maintain these projects, I can grant 
 privileges for github repositories ddbc, hibernated.

 Best regards,
     Buggins


 I wouldn't mind attempting maintaining them


I would help out as much as I can as well (but I lack the skill 
and time to properly maintain it, especially since I mostly care 
about my Postgres usecase, and not much about MySQL or ODBC).
Having ddbc in dlang-community might actually be a neat thing, to 
make it very easy for other contributors to merge stuff and easy 
the maintenance of it.
But ultimately that's Bauss' call, as potential future maintainer 
:-)

P.S:  Bauss: While you definitely will want ddbc as solid 
database abstraction, for Hibernated you might want to change it 
to be less Java-esque and maybe fit your existing ORM better.



 May 07 2018



  parent  Bauss <jj_1337 live.dk>  writes:


On Monday, 7 May 2018 at 18:15:17 UTC, Matthias Klumpp wrote:

 On Monday, 7 May 2018 at 08:26:15 UTC, bauss wrote:

 On Monday, 7 May 2018 at 06:12:19 UTC, Vadim Lopatin wrote:

 On Thursday, 3 May 2018 at 20:49:35 UTC, Matthias Klumpp 
 wrote:

 On Thursday, 3 May 2018 at 18:52:34 UTC, singingbush wrote:

 On Thursday, 3 May 2018 at 10:27:47 UTC, Pasqui23 wrote:

 [...]






 If someone is ready to maintain these projects, I can grant 
 privileges for github repositories ddbc, hibernated.

 Best regards,
     Buggins


 I wouldn't mind attempting maintaining them


 I would help out as much as I can as well (but I lack the skill 
 and time to properly maintain it, especially since I mostly 
 care about my Postgres usecase, and not much about MySQL or 
 ODBC).
 Having ddbc in dlang-community might actually be a neat thing, 
 to make it very easy for other contributors to merge stuff and 
 easy the maintenance of it.
 But ultimately that's Bauss' call, as potential future 
 maintainer :-)

 P.S:  Bauss: While you definitely will want ddbc as solid 
 database abstraction, for Hibernated you might want to change 
 it to be less Java-esque and maybe fit your existing ORM better.


Well it should still be backward compatible tbh. Even if 
abstractions are put on top of it, since some people already rely 
on it.

I agree it would be nice to have it part of the dlang-community 
organization.

If that isn't possible then I'm open to have it a part of 
Diamond's organization if he'd be okay with that. Anyone willing 
to maintain it will get write access.

I believe it's better as a part of an organization rather than as 
a personal repository, because it won't suffer from always 
looking like it's a personal project.

Ultimately it's his call who should maintain it.



 May 07 2018



prev sibling  parent  singingbush <singingbush hotmail.com>  writes:


On Monday, 7 May 2018 at 06:12:19 UTC, Vadim Lopatin wrote:

 Guys,

 If someone is ready to maintain these projects, I can grant 
 privileges for github repositories ddbc, hibernated.

 Best regards,
     Buggins


I'm happy to put some time in



 May 07 2018



prev sibling next sibling parent reply Brian <zoujiaqing gmail.com>  writes:


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?


You can use Entity & Database library:

https://github.com/huntlabs/entity
https://github.com/huntlabs/database



 May 05 2018



  parent reply Matthias Klumpp <matthias tenstral.net>  writes:


On Saturday, 5 May 2018 at 09:32:32 UTC, Brian wrote:

 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?


 You can use Entity & Database library:

 https://github.com/huntlabs/entity
 https://github.com/huntlabs/database


I've tried both a while back, and they are still inferior to 
Hibernated (no surprise there, both projects are very new). There 
was even a "fun" SQL injection issue initially.
So, while in the long run Entity might be a great option, if you 
want an ORM that is as complete as Hibernated is today, it's not 
a solution (I have high hopes for it though).



 May 07 2018



  parent  Matthias Klumpp <matthias tenstral.net>  writes:


On Monday, 7 May 2018 at 18:10:14 UTC, Matthias Klumpp wrote:

 On Saturday, 5 May 2018 at 09:32:32 UTC, Brian wrote:

 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?


 You can use Entity & Database library:

 https://github.com/huntlabs/entity
 https://github.com/huntlabs/database


 I've tried both a while back, and they are still inferior to 
 Hibernated (no surprise there, both projects are very new). 
 [...]


I've looked at this again today, end Entity now seems to have 
OneToMany/ManyToMany relations (for 18 days), which is great news!
I might need to play with this a little again. In any case, if I 
do port my D code to another ORM, I want the next port to be the 
last time I ever do that, because it's a lot of work with quite 
some risk of breakage.

It's also really sad that the existing ORMs don't share a common 
database abstraction library, but well, different people do 
things differently.

In any case, many thanks to Vadim Lopatin for merging the 
existing PRs into ddbc and Hibernated for now! That makes life 
easier already :-)



 May 23 2018



prev sibling  parent  Timoses <timosesu gmail.com>  writes:


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



 Jun 23 2018