Rant on Celko.
Ok, this one is in English (for those the rant is about to notice if ever google upon this).
First of all I have to say I adore Joe Celko. I read with great admiration is columns on SQL and specially those applying hierarchies on top of it.
He even linked us to his book for most of the interesting answers we were looking for. And so I went searching for the book.
I even have to say I have been lucky to have it without having to pay for it because a friend of mine was so kind of sharing it with me.
Celko is smart on his book as he is on his columns. He is even smart enough to put content from his readers in his book, and I do not criticize him for this, in fact I think it is great to sum up the good ideas of several people in one information source catalyzed by someone who is brilliant enough to inspire such responses.
But, and I know we all live in a hurried world, there are things that cannot just be copy-pasted into a book without further testing. A book should not be a pink laced piece of sofware given on AS IS basis and be glad of finding dangling death with it. Perhaps not.
So I spent the whole weekend fighting with chapter 5 of his Joe Celko's trees and hierarchies in sql for smarties.
It is not only slight changes on notation from one line to the next. It is not that some of these changes might be important to go without noticing (like x and y for right and left).
Not about not being told which divisions to make (integer or floating point ones) at any point. That we could figure in the end.
This rant is not about Vadim Tropashko whose work is quoted.
If I were to blame somebody, and blaming anybody I am not, it should be Celko himself or his Elsevier editors. They did not just simply had the time to check.
It is just that some of the code snippets were simply plain wrong in my understanding. And even if we can hack around that it is not nice to see bad things being published by a big firm under a big name.
For instance let us take:
CREATE FUNCTION Child_Denominator
(IN num INTEGER, IN den INTEGER, IN child INTEGER)
RETURNS INTEGER
LANGUAGE SQL
DETERMINISTIC
RETURN den * (child * child);
And then it says:
For example, the third child of the node '1' (encoded as 3/2) is the node '1.3' (encoded as 19/16).
But if we do:
den = 2
child = 3
we would get according to the code mentioned: 2 * (3 * 3) = 18, not 16.
And I had to fight to come with an implementation at the end reversing the parent equations to get the child ones. Not difficult but unexpected.
And this type of thing goes on an on. On other fields, I could cite here papers like from Chib and Greenberg with some mistakes in. I even helped correcting some minor things in papers from people I know.
Of course I am not free of making mistakes of my own and I am grateful enough so as to reckon that without the work of all these wonderful people I would have not had such brilliant things in front of my eyes, the ideas are always theirs.
But guys, simply check what you write on your books. Part of my scarce weekend time was devoted to this and my projects delayed.
You are the big guns.
Thanks for being so.
End of rant.
