Hello,
We are going to trouble of deeply investigating issues, creating test cases and raising issues to help improve the quality of Hibernate but there has been an agressive approach to reject or simply not look at obvious test cases showing reproducable issues - this is pretty frustrating.

As a simple example here are some issues that currently impact us that we are currently having to workaround:

HHH-5733 - Just run the test case and you'll see the reproducable issue.

HHH-5378 - This is a real problem we are seeing. However it has been marked as resolved and rejected and resolved - so we cannot re-open therefore we opened the following:

HHH-5732 - Which instead of being addressed has just been marked as resolved and a duplicate of 5378 without any comment or discourse.

The salient point of this bug is "even Hibernate documentation http://docs.jboss.org/hibernate/core/3. ... ns-indexed uses example which fails when executed with 3.6.0.Final version. Test case attached"

Hopefully these and other issues which have been recently rejected agressively can be re-evaluated with a little more care and attention - even a comment would be better to explain the investigation from the Hibernate side and provide context to the closed bugs.

see also: viewtopic.php?f=1&t=1009031

HHH-5722 also rejected - We also see this issue - Surely the issue should remain open so there is a chance to provide the test case requested

hi,
I quickly looked at those issues. They seem to be mostly duplicates of open issues, or like in case of HHH-5722 the issue was closed in lack of a testcase: apparently Gail promised to reopen it in case someone could provide one. Opening duplicates doesn't help, actually they make a mess of the issue tracker as we have the sane policy to not delete them.

Please consider that providing test cases is of utter importance to be able to fix anything, as when there's a bug most likely you're doing something unexpected to the one implemented the feature.

Being an open source project, you're invited to provide patches, solution drafts, ideas: all we ask to be able to use this code for free is that you help a bit; if you don't know how to fix it, we'll try looking at it but among all issues the ones which are well documented and reproducible will always receive priority: easier for us and rewarding to people who showed some attitude to help.
Github pull requests are checked and handled very quickly!

About the "aggressive approach to reject", I'm sorry for that and I'm relaying this message to the team, hopefully we can find a way to improve on this.

And what about the
http://opensource.atlassian.com/project ... e/HHH-5716

I provided test case and fix also.

When it is a duplicate, why it is not marked as one? I wasn't able to find that issue in tracker. If it is already fixed,
why it is not mentioned there? If the comment is only -> go to forum, and then rejected...

HHH-5716 has test case, and patch also. What is problem there?

Hi,
thanks for pointing out, that was likely a mistake; I'm pinging Gail. If there's something bad with your issue/test/fix we usually provide at least a short explanation. sorry.

Please forgive me for being brief in the JIRA issues. I'm working 12+ hours/day trying to get things worked out for 3.6.1.

"Please use the user forum for help" means that I spent a fair amount of time reading through the issue and test case and I found that the problem reported was due to user error or due to some known issue.

In those cases, the appropriate thing would have been for the reporter to find the answer themselves using the documentation or the user forum.

I do make mistakes sometimes. If someone provides compelling information in a comment or points me to a forum topic that clearly shows the problem and why it's a bug, I have no problem reopening the issue.

Yes, I could have answered the question by providing a comment when I reject an issue. As a rule, I don't, because that would encourage people to open issues rather than using the forum.

"I believe this is a duplicate of another reported issue" means that I don't remember exactly which issue it duplicates. I do not resolve issues until a duplicate issue is found.

Duplicate issues waste time -- both for developers and for users. It takes too much time for me to compare issues and test cases, and using the various test cases to ensure that a fix for one issue also fixes other issues I believe to be duplicates.

This is time that could and should be spent on fixing bugs.

That said, here are some very brief comments about the issues mentioned here.

HHH-5733:

>>> "I think that the unit test attached is simple enough and clear showing where issue occurs.".

If there is no description and it is a real problem, you can be sure that a duplicate will be created because a user did not open the test case. Until this issue has a description, I will not review it.

>>> "Will you please point me to the issue which this one might duplicate?"

It is the reporters responsibility to look for duplicates.

HHH-5378 and HHH-5732:

These are duplicates. I was mistaken when I rejected them. I've reopened HHH-5732 because it had more votes/watchers.

HHH-5722:

I spent time looking at this issue, writing my own test case (that should have been provided by the reporter), and even explained why the information provided was not sufficient to reproduce the issue. I've already said, "If you provide a test case that reproduces your issue, I'll re-open." No test case yet.

HHH-5716:

Because the Set has mappedBy=, elements should be removed via transport.setDeliveryNode( null ).

OK, back to fixing bugs...

Gail

Hi! I do not agree. The problem here is not that the collection is mapped using mappedBy. It could be
also mapped directly.

The problem is, that it is LAZY loaded.

Why than this code works and I think is correct:

node.getDeliveryTransport().iterator();
node.getDeliveryTransport().clear();

But when ommiting the iterator() (which loads the lazy collections) the code fails:

node.getDeliveryTransport().clear();

I still think, this is a regular bug.

Hello,

I am encountering the same issue.

Since, with jpa, at runtime, you can't choose when to cascade operations and when not to on the same collection, I need to write a manual cascading mechanism. This issue is preventing me of achieving this task.

Calling clear method twice do work ... But of course, I can't use that.

Does the patch included in http://opensource.atlassian.com/projects/hibernate/browse/HHH-5716 fixes the issue?