Derby
  1. Derby
  2. DERBY-2504

SQL warning "01501: The view V21VIEWTEST has been dropped" can be lost (ie. not seen when it should be)

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 10.2.1.6, 10.2.2.0, 10.3.1.4
    • Fix Version/s: None
    • Component/s: SQL
    • Urgency:
      Normal

      Description

      Example, grantRevokeDDL test has this SQL and correct output:

      revoke select on t11ViewTest from public;
      0 rows inserted/updated/deleted
      WARNING 01501: The view V21VIEWTEST has been dropped.

      But if instead the statement is prepared and another statement prepared before the execution then the warning will not appear

      prepare R1 as 'revoke select on t11ViewTest from public';
      ij(MAMTA1)> prepare V1 as 'values 1';
      ij(MAMTA1)> execute R1;
      0 rows inserted/updated/deleted
      ij(MAMTA1)> execute V1;
      1
      -----------
      1
      1 row selected

      If I don't prepare V1 then the exception is seen, so it's not the prepare causing the issue.

      1. repro.zipx
        2 kB
        Lily Wei
      2. Derby-2504.diff
        1 kB
        Lily Wei

        Activity

        Hide
        Lily Wei added a comment -

        I am adding getLastActivation on ViewDescriptor.makeInvalide for the case of DependencyManager.INTERNAL_RECOMPILE_REQUEST because it helps to cases like repro2.sql. If the privilege was granted and being revoked, revoke it again will fall to case of INTERNAL_RECOMPILE_REQUEST. In that case, the dependency object is still being removed. I think users should get warning for that. However, Dan's point is still true, getLastActivation() has no guarantee of the current executing statement at runtime as repro3.sql demonstrate. I am posting this try fix because I don't understand what is doing on in repro3.sql. When break at 'execute R1', I got the case of DependencyManager.INTERNAL_RECOMPILE_REQUEST, I step in to
        lcc.getLastActivation().addWarning(
        StandardException.newWarning(
        SQLState.LANG_VIEW_DROPPED,
        this.getObjectName() ));
        However, the debugger just jump in the the default case and stop at SanityManager.THROWASSERT("did not expect to get called");

        I believe in repro3.sql case, it should raise a warning. If there is no ActivationObject, I can code it as try and catch. Also, if default case is really being executed, why did not print to derby.log. What am I missing?

        Show
        Lily Wei added a comment - I am adding getLastActivation on ViewDescriptor.makeInvalide for the case of DependencyManager.INTERNAL_RECOMPILE_REQUEST because it helps to cases like repro2.sql. If the privilege was granted and being revoked, revoke it again will fall to case of INTERNAL_RECOMPILE_REQUEST. In that case, the dependency object is still being removed. I think users should get warning for that. However, Dan's point is still true, getLastActivation() has no guarantee of the current executing statement at runtime as repro3.sql demonstrate. I am posting this try fix because I don't understand what is doing on in repro3.sql. When break at 'execute R1', I got the case of DependencyManager.INTERNAL_RECOMPILE_REQUEST, I step in to lcc.getLastActivation().addWarning( StandardException.newWarning( SQLState.LANG_VIEW_DROPPED, this.getObjectName() )); However, the debugger just jump in the the default case and stop at SanityManager.THROWASSERT("did not expect to get called"); I believe in repro3.sql case, it should raise a warning. If there is no ActivationObject, I can code it as try and catch. Also, if default case is really being executed, why did not print to derby.log. What am I missing?
        Hide
        Rick Hillegas added a comment -

        Triaged for 10.5.2: assigned normal urgency.

        Show
        Rick Hillegas added a comment - Triaged for 10.5.2: assigned normal urgency.
        Hide
        Daniel John Debrunner added a comment -

        This is because the ViewDescriptor.makeInvalid() is using the getLastActivation() method on LanguageConnectionContext.
        At runtime there is no guarantee that the currently executing statement is the last activation.

        I just noticed this because the getLastActivation() method caught my eye, I couldn't see any valid reason for such a method, it should be removed as part of this bug fix.

        Show
        Daniel John Debrunner added a comment - This is because the ViewDescriptor.makeInvalid() is using the getLastActivation() method on LanguageConnectionContext. At runtime there is no guarantee that the currently executing statement is the last activation. I just noticed this because the getLastActivation() method caught my eye, I couldn't see any valid reason for such a method, it should be removed as part of this bug fix.

          People

          • Assignee:
            Unassigned
            Reporter:
            Daniel John Debrunner
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development