tag:blogger.com,1999:blog-8677649049588007585.post3677256757496218878..comments2016-04-11T07:44:28.140+01:00Comments on PL/SQL Challenge: Questions raised about 24 November quiz and program invalidations (1709)Steven Feuersteinhttp://www.blogger.com/profile/16619706770920320550noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-8677649049588007585.post-50142959518615993802010-11-27T20:29:39.106+00:002010-11-27T20:29:39.106+00:00Bora, the original statement is not the same as sa...Bora, the original statement is not the same as saying that the likelihood of the minimum salary changing is greater than the likelihood of any other change occurring. This can be demonstrated using the three cases you mentioned. For the sake of simplicity assume that these are the only changes possible. If the associated PL/SQL code is written such that any of these changes results in other objects being invalidated, then the probability that a change will invalidate other objects is 100% regardless of the probability of each change even if these probabilities differ.<br /><br /> If the code associated with case one is implemented such that changing its value does not invalidate other objects then the probability that a change will invalidate other objects is reduced. If all three changes are equally likely then there is a ~67% chance that a change will invalidate other objects since two of the three will invalidate other objects. If the probability of the first case is half that of each of the other two cases then there is an 80% chance that a change will invalidate other objects. If the probability of the first case is twice that of each of the other two cases then there is a 50% chance that a change will invalidate other objects.jhall62http://www.blogger.com/profile/10339038131928463003noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-29068471509051727312010-11-27T16:10:20.749+00:002010-11-27T16:10:20.749+00:00I know that this conversation has lasted too much ...I know that this conversation has lasted too much and this is my last comment on this issue.<br /><br />When I scan the comments, the one which belongs to jhall62 is the most relevant one and I think exactly the same as jhall62.<br /><br />However, my problem is about the likelihood measure.<br /><br />I am saying that there can be many thing which may force us to alter any particular point in our software. And salary change is just one of those things and it is not so true to imply that salary change is more likely to occur.<br /><br />I am giving 3 examples:<br /><br />Case 1: Minimum salary changes <br /><br />Effect A: If we are providing the salary value by using a constant located in the package spec, this causes invalidations to occur on programs referencing our package.<br /><br />Effect B: If we are returning the salary value from our function there will be no invalidations on the referencing programs.<br /><br />Case 2: Minimum salary data type changes from integer to number with decimal point.<br /><br />Effect: No matter we are using a spec constant or a function to supply the min salary value, referencing programs get invalidated.<br /><br />Case 3: Minimum salary policy changes: If the seniority of the employee is more than 10 years then the salary is 20K, else 10K.<br /><br />Effect A: In the case of using spec constant, we can create 2 constants for senior and junior employees and this change invalidates the refencing programs.<br /><br />Effect B: If we are using the function to return the minimum salary, we have to alter the function's interface by adding a numberic in parameter that carries the employee's seniority level. This change makes referencing programs invalidate.<br /><br />Now let us evaluate the statement of the option that was said to be a correct one: <br /><br />"The function implementation reduces the likelihood that program units will be invalidated thus requiring fewer recompilations of the application code base."<br /><br />For case 1, this is true.<br />For case 2, this is not true.<br />For case 3, this is not true.<br /><br />Now, how can we say that using the function for providing the minimum salary reduces the likelihood that program units will be invalidated thus requiring fewer recompilations?<br /><br />I think we cannot say that becuse in case 2 and case 3, whether or not we are using a function to provide the minimum salary, the referencing programs get invalidated.<br /><br />The original statement is logically equivalent to the one below:<br /><br />Case 1 is more likely to happen among the other cases.<br /><br />And I think this is not true, either.<br /><br />That is all I am talking about. And of course I know the advantages of information hiding, high cohesion, low coupling in the software systems, but this is not the point in this quiz.<br /><br />Thank you and goodbye for this issue.Borahttp://www.blogger.com/profile/07302203351181934021noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-82689147483725832332010-11-27T12:54:50.915+00:002010-11-27T12:54:50.915+00:00Recompilation is a trouble as it cascades. so the ...Recompilation is a trouble as it cascades. so the choice scoring is absolutely valid.al0http://www.blogger.com/profile/15743792964167204705noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-82613188731276440012010-11-26T21:17:56.132+00:002010-11-26T21:17:56.132+00:00There is a very little bit of ambiguity: "inv...There is a very little bit of ambiguity: "invalidate" - status or state? But keyword "recompilation" does not left any other choice: only status.<br />I 'd also fall into this little trap. But no rescoring is required.<br /><br />From practical point of view recompilation is not a trouble because it happens implicitly. The real trouble for 24*7*365 is invalidated state. So conceptuality of this choice is zero. It does not teach. It does not show good practice.Vitaliyhttp://www.blogger.com/profile/03394959689295703518noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-21666885040092287462010-11-26T09:10:46.809+00:002010-11-26T09:10:46.809+00:00Off cause Steven and Jhall62 are right. Hiding con...Off cause Steven and Jhall62 are right. Hiding constants in a package body makes it less likely that other packages are invalidated in case the constants are to changed.<br /><br />Having said that, I think it is a very bad practice to use constants in procedures or functions or packages (headers or bodies) to define values that are likely to change. I would never do that.<br /><br />Constants should only be used for values that are never changed, such as status codes from UTL_HTTP or error codes from UTL_FILE. <br /><br />Values that are likely to change such as a minimum salary belong in a database table.<br /><br />Thus in my opinion the quiz answer makes us realize that the second worst practice (to hide constants defining values that are likely to change in a package body) is better than the worst practice (to expose constants defining values that are likely to change in a package header).molhttp://www.blogger.com/profile/04293152612634716250noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-74688541445597257372010-11-26T08:32:54.149+00:002010-11-26T08:32:54.149+00:00Don't rescore. But the quiz is difficult. It i...Don't rescore. But the quiz is difficult. It is about opinions, expectations and experience of the reader. The moment I was reading the quiz I was already thinking about the options. And in general you are correct.Wim de Langehttp://www.blogger.com/profile/05505341375827859005noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-61527419259885816842010-11-26T00:07:12.260+00:002010-11-26T00:07:12.260+00:00I thought the style of question may illicit a few ...I thought the style of question may illicit a few responses, but I thought the answers were pretty clear cut. It's a common scenario that pl/sql developers should be aware of and consider when designing package structure. My 5 cents.Scott Wesleyhttp://www.blogger.com/profile/18106937181788036683noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-70202829385059698292010-11-25T22:19:45.928+00:002010-11-25T22:19:45.928+00:00The statement of the quiz establishes the minimum ...The statement of the quiz establishes the minimum salary rule as the context for each of the given choices; repeating this in the choices would be redundant. This context, however, is not necessary for the "invalidation" choice because of the following:<br /><br />The probability that any rule change will invalidate program units is directly related to the number of rule changes that cause program units to be invalidated divided by the total number of possible rule changes. Structuring one’s code such that a particular rule change will not result in invalidating other program units does not change the total number of possible rule changes, thus the total probability that any rule change will invalidate program units is reduced.jhall62http://www.blogger.com/profile/10339038131928463003noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-67566188497221282652010-11-25T19:28:05.405+00:002010-11-25T19:28:05.405+00:00Hello,
For "Point #1 makes some very interes...Hello,<br /><br />For "Point #1 makes some very interesting observations about the dynamic nature of our applications, but I don't think this perspective changes the fact that by hiding the literal value in the package body, you can avoid invalidations and therefore recompilations when the value changes."<br /><br />We are not discussing the fact that we can avoid invalidations by encapsulating the appropriate structures in the package bodies.<br /><br />We are discussing the corectness of the statement in the option:<br />"The function implementation reduces the likelihood that program units will be invalidated thus requiring fewer recompilations of the application code base."<br /><br />This statement is not mentioning about the changes on minimum salary. Therefore, it is not correct or complete. If the statement was like below:<br /><br />"The function implementation reduces the likelihood that program units will be invalidated thus requiring fewer recompilations, which caused by changes on salary, of the application code base."<br /><br />It would be correct and complete.<br /><br />As the original statment is not including any information about salary changes, it is not possible to know that the minimum salary is very likely to change. Without that rigid information about salary changes, the likelihood of the salary change cannot be an issue beyond an anticipation, which does not make the original sentence true.<br /><br />So, I think the quiz must be re-scored.<br /><br />Regards.Borahttp://www.blogger.com/profile/07302203351181934021noreply@blogger.comtag:blogger.com,1999:blog-8677649049588007585.post-16756085176797872542010-11-25T12:31:39.002+00:002010-11-25T12:31:39.002+00:00I agree, the function implementation means that ch...I agree, the function implementation means that changes to the constant will never invalidate any other code in the system, since only the body needs to be recompiled.<br /><br />To avoid the possibility of the ORA-04608 error (which is due to the value of the constant being kept in the session PGA, the first time the session calls any routine in that package), it could be written like this:<br /><br />CREATE OR REPLACE PACKAGE BODY app_config<br />IS<br /> FUNCTION minimum_salary<br /> RETURN PLS_INTEGER<br /> IS<br /> c_minimum_salary CONSTANT PLS_INTEGER := 100000;<br /> BEGIN<br /> RETURN c_minimum_salary;<br /> END minimum_salary;<br />END;<br /><br />The downside is that this means the constant cannot be referred to elsewhere in the same body. Of course, it could be argued that the value should only ever be accessed via the function anyway.jeffkemponoracle.comhttp://jeffkemponoracle.com/noreply@blogger.com