ancestry: Falseful changelog, incorrect README and broken code in 4.3.0

@kshnurov I love the work @kbrock is doing, please behave

@kshnurov your communication style is quite combative. These attacks are getting tiring. I’d rather be spending my time merging your PRs than fighting you.

You had the option to put in a PR or to attack me and call me a liar. You chose the latter. It feels like you often choose the attacking route.

I could have merged a PR that you submitted without a second though, but here I am defending myself against your most recent attack. I’m sorry @stefankroes that you are dragged into this.

---

Thank you for finding another typo. We were working on flatten_arranged_nodes (and the alternative to arrange_as_array. As you’ll notice, arrange is the common word there. Yes, I made a mistake. It seems like a reasonable mistake but I will change it to sort_by_ancestry to make sure no one is misguided. Saying I was intentionally lying is a bit of a stretch.

I’d imagine your frustration would be heightened since you have clearly stated that you want to delete this method from the code base.

But we can’t delete this method. It is needed. The original form has been in the wiki for a long time with people updating it. And just last week someone submitted a few issues wanting to do this very thing. I need to go in there and s/arrange_as_array/sort_by_ancestry/g. But again, you are capable of contributing instead of attacking.

And that sums up a lot of our tension. You solve a problem in a certain way. I’ve repeatedly explained that other developers may use different solutions because they have different use cases. There are trade offs. Your responses suggest that my response does not resonate.

---

You have solved your problem using ruby callbacks. But there are other solutions where an update in pure sql is mandatory. Bringing back all those records into ruby would not complete in a reasonable amount of time, let alone locking tables for that long. I’ve shown you how rails offers both solutions, but you just insist that I am negligent by allowing “broken” code in this gem.

---

Now as for collation, I’ve explained this before.

Ancestry was written in a world where it assumes an ascii character set, with POSIX or C collation. And when it was written, that was a reasonable solution. Now that we are in a UTF-8 world, we need to ask the indexes to act in the way the gem was designed.

The documentation behind collation was not optimal. I took a stab at making it better and you have shared some good knowledge. But back to the backwards compatibility comment, I can’t just swap a string field over to binary. I have added a section with your solution to the README. I’m trying my best to introduce your knowledge in a way that does not break existing installations. I tried to run all my suggested scenarios with a benchmark script ensuring that indexes were used on both mysql and postgres.

If you have a problem with how I represented your knowledge, please put in a PR instead of attacking me. The documentation PR was open for a number of days. I didn’t think you had a problem with it. You just went radio silent on the project.

Since it is just a README file that is easily updated with a PR and not really tied to a release, I went ahead and released the gem. You have been asking me to release the gem for a while now. I wasn’t expecting you to attack me for releasing it.

---

Your latest PR just does too much. I told you that it changes too much but you just state that I can’t see the obvious.

After you stated you would not split up the PR, I have been splitting apart the code and pulling out PRs. Any code change potentially introduces bugs. So I am pulling out the various changes to make it easier to diagnose bugs in the future.

I’ve been maintaining this gem for many years. So making sure we can address bugs in the future is my number one priority. If that slows down development in the short term, then that is acceptable to me. Contributors come and go. They swoop in demanding that their code gets merged, raise a fuss, and then they leave the maintainer to maintain the code.

I appreciate the knowledge you have shared, but please cut back on the attacks.

I am adding back the backwards compatible tests that you dropped in https://github.com/stefankroes/ancestry/pull/597.

I didn’t drop anything! What is wrong with you? Read the code! BTW, it is your own code, I just renamed STRATEGY to FORMAT in #597. It is testing both strategies, without FORMAT it’ll be the default materialized_path.

bundle exec rake
FORMAT=materialized_path2 bundle exec rake

You’ve added format to matrix in #624, which is really good, but you didn’t remove the first bundle exec rake, and now all tests are run twice. IDK how you cannot see two consecutive bundle exec rake here.

@stefankroes you still love this?

@kbrock we’re from very different cultures in terms of criticism and feedback. What you see as an attack is absolutely normal in my culture (and many others), where solving a problem is much more important than keeping everyone happy.

And when someone acts irresponsible and breaks things - we’re saying it out loud, for the sole purpose of fixing the problem. If you take that personal - just don’t.

That’s an excuse. You can be critical of the code and provide failing tests and solutions in pull requests without being negative towards anyone. If your concerns aren’t well understood, demonstrate them in failing tests, issues and draft pull requests.

Where are the pull requests to fix the things you’re still concerned with? Perhaps you can better demonstrate your ideas in pull requests tested on at least a few databases and then offer to test them more thoroughly if your proposal is desired.

@jrafanie have you even looked at my PRs and comments on issues before writing this? I’ve done all of it, spent days to figure things out, test, point out bugs, and propose solutions. And after all that @kbrock just releases a new broken version without asking anyone.