The 28 March quiz on object type hierarchies asked players to identify those keywords that "that are needed to create an object type hierarchy". Several players wrote to object to the way the quiz was scored:
1. "The question for this quiz was: Which of the choices are keywords that are needed to create an object type hierarchy? (with the word "hierarchy" in bold letters). You have marked the answer "CREATE TYPE" ([ 10065 ]) as correct with explanation "We use the CREATE TYPE statement to create an object type, so this is definitely needed!". Of course, it is obvious that you cannot create a type without CREATE TYPE keywords, but with "hierarchy" being bolded in the question I concluded that we only need to mark the keywords that are strictly used for creating object type hierarchies. That's why I left this answer unmarked. I think you should mark this answer as correct for everyone because of ambiguity in the question."
2. "In my opinion the keyword "INSTANTIABLE" is needed for at least one class because otherwise you can't instantiate an instance of any object in your hierarchy."
3. " I do not agree with your evaluation of the right answers. You have NOT mentioned that the hierarchy is supposed to have AT LEAST two levels. It is true that a hierarchy with only one level is trivial, but it is still a hierarchy. For such trivial hierarchies the first two choices are not mandatory. This is like the empty set in mathematics. It is still a set even it has no element. It is trivial but exists!"
And my responses:
1. I don't think you can say "Of course" I am correct, but then believe that the choice is not correct. I understand your concern about the word hierarchy being bolded, but it doesn't take away from the fact that you need CREATE TYPE to accomplish this.
2. INSTANTIABLE is the default for an object type and method, so I don't see why this would be needed.
3. While your objection may be theoretically correct, I think that it is plenty clear from the emphasis on hierarchy that the intention of the question was to identify the keywords needed to create a non-trivial hierarchy.
I do not believe that any change in scoring is required. Your thoughts?
Cheers, Steven
The PL/SQL Challenge (www.plsqlchallenge.com) offers a daily quiz on the PL/SQL language, through which thousands of Oracle technologists demonstrate and deepen their knowledge of PL/SQL. This blog contains posts by the PL/SQL Challenge founder, Steven Feuerstein, as well as comments from players.
I agree, there is no reason to adjust scoring based on any of the objections mentioned in the post. The question unambiguously asked which of the keywords are required to create an object type hierarchy. CREATE TYPE must be used when creating a type hierarchy regardless of whether or not it may be used for any other purpose. INSTANTIABLE is not required since its effect is implicit to type creation.
ReplyDeleteI would argue that the third objection is not even theoretically correct. A hierarchy is a nested set. To be nested one object must be contained within another, therefore a hierarchy cannot have less than two elements and those elements must be at different levels.
Hello Steven,
ReplyDeleteIn my opinion, this quiz was one of the most clear and unambiguous ones that have ever been played on the Challenge.
I don't think that any score change should be done.
Again, it comes to the reason of why a player might have considered one choice as incorrect, and NOT because of that choice was indeed incorrect (ex. the CREATE TYPE).
This rather reminds us of the other quiz one day before, where the "IF AND ONLY IF" condition was relevant and emphasized as such in the quiz introduction as a strict requirement.
Here the quiz clearly asked for key words that are strictly necessary for creating a type hierarchy, but it did not specify in any way that these key words should be "reserved" exclusively for this purpose.
If so, then one who considered CREATE TYPE as incorrect should have also considered UNDER to be equally incorrect, because it is also used for defining object views hierarchies and not just
for object type hierarchies.
It is almost obvious that probably any single keyword taken in isolation is NOT reserved in SQL or PL/SQL for one and single purpose, and, if it is today, chances are that it will be used in some combined term (keywords sequence) in an upcoming version.
Regarding the hierarchy, I think that the term "hierarchy" by itself already implies the presence of at least two members where one is a "subordinate" of the other.
It is not the same as an empty set, which IS a "subset" of any other set.
Maybe this could have been the case if objects in SQL would have automatically inherited from an initial "ultimate root" object, like the "Object" class in Java, which forms by default a hierarchy with any other (single) class that has no superclass defined explicitly.
But a single object type in SQL is NOT a subtype of any other object type, if not explicitly specifying such a relationship.
SQL is kind of a "God-less" world for object types.
Thanks & Best Regards,
Iudith
I agree that a hierarchy of one is not particularly useful and I read and answered the questions on the assumption of 2 or more.
ReplyDeleteHowever, is an assumption of 2 or more a deviation from precedent in other questions?
Haven't there been questions that, in part, hinged on evaluation of empty (null) strings when "normal" usage would be for a populated string.
Haven't there been questions where we were tested on our handling of trivial cases with empty collections or no_rows_found?
One could argue that those are run-time differences as opposed to one-time DDL declarations. But we've had another quiz (with contested results) where we were supposed to notice the absence of a table which would have caused an error during the setup portion of the quiz (I believe it was with the existence/non-existence of the error logging table). I recognize that's not exactly the same thing here, but it does seem to my memory (which may be faulty) that we've been tested on our ability to find the trivial/empty cases.
So, while the competitor in me wants my points, especially as the quarter closes and I find myself short again. I think I have to argue that an assumption of 2 or more is not valid.
And, while I couldn't find a statement in the Object-Relational documentation that said "hierarchies have at least two types"
I did find this phrase on page 2-35
"All types that belong to a type hierarchy are assigned a non-null typeid that is unique within the type hierarchy. Types that do not belong to a type hierarchy have a null typeid."
Since that's as close as I could find to anything "official" I built a test case around it.
First I build a hierarchy of one (not final) and then a stand-alone type (final). Oracle does recognize them as distinct types.
CREATE TYPE plch_hierachy_one AS OBJECT(n NUMBER) NOT FINAL;
CREATE TABLE plch_hierachy_test (t plch_hierachy_one);
INSERT INTO plch_hierachy_test
VALUES (plch_hierachy_one(1));
SELECT sys_typeid(t) FROM plch_hierachy_test;
DROP TABLE plch_hierachy_test PURGE;
DROP TYPE plch_hierachy_one;
CREATE TYPE plch_hierachy_one AS OBJECT(n NUMBER);
CREATE TABLE plch_hierachy_test (t plch_hierachy_one);
INSERT INTO plch_hierachy_test
VALUES (plch_hierachy_one(1));
SELECT sys_typeid(t) FROM plch_hierachy_test;
DROP TABLE plch_hierachy_test PURGE;
DROP TYPE plch_hierachy_one;
Sean, if I understand your post properly, you are saying:
ReplyDelete1. Oracle says it's a type hierarchy if the typeid is not null.
2. If you do not include a FINAL clause on a type, then it has a typeid.
3. Therefore, a single type defined with NOT FINAL is a type hierarchy.
In other words, if you might at some point add a subtype under the type, then it's a type hierarchy now. 'Cause that's the only difference between the two types: whether or not it is defined as NOT FINAL.
Oh, and that also means that if we accept this logic, that NOT FINAL *is* needed but UNDER is not. So now we are down to just one choice (the first) that should be considered for re-scoring. And that makes me even less convinced of the need to do any re-scoring.
I think there is general agreement that the intention of the question is clear, and the point of a hierarchy is clear: you don't have just a single type.
I am not supposed to provide quizzes that trick people, and I think that if I had scored this according to the principle that "one type is a hierarchy" (UNDER is not needed), then I would hear from many players charging that I had tricked them. And what about how I scored NOT FINAL? If you think that one type makes up a hierarchy, you'd say NOT FINAL is not needed - and you'd be "wrong." And likely very irritated with me.
Tricky? Yes. A trickiness that has to do with semantics and not the least bit with code? Yes.
Oracle's not always great at providing clear definitions for many different terms in SQL and PL/SQL. So we often end up relying on a common sense understanding, and I think that's what works best and applies here.
Sure, you found a line of text that provided an insight into how and when Oracle assigns typeids (and I thank you for the effort!), but I think that is just a "side effect" of the need to have a typeid in place when the first subtype is created (when, I would say, the hierarchy is defined), not something that should be used to formalize a definition.
SF
Basically I am a mathematician forced by life to become IT professional.
ReplyDeleteFrom this perspective I have to say that:
1. If implicit assumptions were accepted in mathematics, then we would never have axioms.
2. The edge cases can prove to be a whole theory: one edge case is that given a line and a point outside of this line there is only one parallel to the line that contains that point.
3. I am totally against the logic that tends to skip some edge cases based on "common sense". Such kind of logic is useful in business analysis, in psychology too but I find it really senseless in a professional quiz where any case, trivial or not, useful or not is possible. A professional quiz should assume that in practice any case may be seen at least once.
4. Common sense has no limit well defined. Should one assume his common sense is better than others? If so, I can say a lot about many quizzes. Is this the idea of a professional quiz? To lead to endless debates on what may be considered common sense or not?
5. Common sense may contradict the logic: You have a hotel with infinite number of chambers and it is full. Can you accommodate 5 new tourists in that hotel? Common sense said NO, logic said YES. Logic is right.
Cristi,
ReplyDeleteI am sorry that you have been forced to be a programmer, but happy that you get to demonstrate the strength of your logic skills at the PL/SQL Challenge! It is overwhelming and I concede.
I will give credit for the UNDER choice to you and anyone else who submits feedback on this quiz that they believed a hierarchy of one was possible and legitimate.
I will change the quiz to state "hierarchy of at least two types".
Cheers, SF
Hello All,
ReplyDeleteA propos the SYS_TYPEID function itself and its NULL or NON-NULL values for FINAL or NOT FINAL object types, I still think that a single object type defined as NOT FINAL is not yet a hierarchy, it only gives that object type the potential to become a member of a hierarchy.
I am little bit worried of the fact that, if such a clear quiz like this one could raise different interpretations, then from here on probably most of the authors will tend to introduce too extensive explanatory wording in each and every quiz presentation, in an attempt of trying to avoid any possible objections.
Logic does have of course its place of honor in every positive science, but we should still keep a notion of a "quiz wording common sense" (as opposed to daily life common sense) in what concerns the eventual problematic edge cases.
A small addition, like here specifying "hierarchy of at least two types" or in the quiz of March 27 "collection indexed by non-empty strings" would be ok, except, of course, for a quiz where the edge case itself was the whole point (like the quiz from March 22).
I am pretty sure that with too excessive wording, many quizzes would become too cumbersome and for many players, especially among those who are not native English speakers, playing will become more of a linguistic challenge than a PL/SQL challenge.
I am also a mathematician, and even share in a certain point Cristi's way of having become a programmer, (in addition to sharing our native language and probably our school)
but I think there should not be at any point any conflict between the two, I can just confirm after 30 years of programming that being a mathematician and mastering a strong logic can only help you to be a better programmer.
Thanks a lot & Best Regards,
Iudith
Iudith,
ReplyDeleteThank you for your answer. I must say your post has a strong reason when speaking about excessive wording.
I think Mr. Steven Feuerstein ended the dilemma which, in fact is inherent to any test where the response cannot be motivated. Sooner or later some questions will fall into different interpretations.
The fact that concerned me was not to apply penalties for those that answered by explicitly thinking at the singularity too.
Anyway, the PLSQL-Challenge quizzes are greater than I can express in words.
Strictly speaking an empty hierarchy (with no types in it) is hierarchy as well :)
ReplyDelete