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

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

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/efa38c50effdd77e973b174feea89016b8d1fa1f 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

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/efa38c50effdd77e973b174feea89016b8d1fa1f 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

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.

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

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.

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

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.

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