Derby
  1. Derby
  2. DERBY-159

When Derby runs in Network Server mode, client does not receive warnings generated by Derby - should get documented

    Details

    • Urgency:
      Normal
    • Issue & fix info:
      Repro attached

      Description

      A simple code below will demonstrate that warnings generated by Derby running in Server mode do not make their way to client. The client code below is trying to create the database db1drda which already exsits. Server generates a warning for that but the client cde below does not print it.

      con = DriverManager.getConnection("jdbc:derby:net://localhost:1527/db1drda;create=true:retrieveMessagesFromServerOnGetMessage=true;", "app", "app");
      SQLWarning warnings1 = con.getWarnings();
      System.out.println("database exists, should get warning");
      while (warnings1 != null)

      { System.out.println("warnings on connection = " + warnings1); warnings1 = warnings1.getNextWarning(); }
      1. d159.java
        3 kB
        Myrna van Lunteren

        Issue Links

          Activity

          Hide
          Kathey Marsden added a comment -

          I think this type of warning cannot be sent within the protocol specification. I think it will have to be changed to a documentation issue.

          Show
          Kathey Marsden added a comment - I think this type of warning cannot be sent within the protocol specification. I think it will have to be changed to a documentation issue.
          Hide
          David Van Couvering added a comment -

          Hm, it bothers me that we need to document that you don't get warnings in the network client because of a limitation in the DRDA protocol. What is the right thing to do for the Derby community here? If the DRDA standard is constraining what we can do with the network client (for example, sending warnings over the wire, supporting larger encryption keys, etc.), then what is our policy? One could argue that we should be able to extend our protocol to be a superset of DRDA, or maybe add support for an alternate protocol using some kind of plugin scheme. I am uncomfortable with the feeling that our hands are being tied by the DRDA spec.

          Are there motivations within the community to be compliant with DRDA? I recognize this has value for the IBM universal driver, but is compatibility with this driver a clear requirement for the Derby community?

          Thanks,

          David

          Show
          David Van Couvering added a comment - Hm, it bothers me that we need to document that you don't get warnings in the network client because of a limitation in the DRDA protocol. What is the right thing to do for the Derby community here? If the DRDA standard is constraining what we can do with the network client (for example, sending warnings over the wire, supporting larger encryption keys, etc.), then what is our policy? One could argue that we should be able to extend our protocol to be a superset of DRDA, or maybe add support for an alternate protocol using some kind of plugin scheme. I am uncomfortable with the feeling that our hands are being tied by the DRDA spec. Are there motivations within the community to be compliant with DRDA? I recognize this has value for the IBM universal driver, but is compatibility with this driver a clear requirement for the Derby community? Thanks, David
          Hide
          Myrna van Lunteren added a comment -

          [10.5.2 Triage]
          This issue may have gotten into a confusing state because of David's concerns...
          Whether the community should find another network connection model than NetworkServer/DerbyClient and/or another protocol than DRDA is a different issue from what we see here - unintuitive current behavior.

          I think making this a documentation issue makes sense. But where should this get documented?
          This is a network server/client limitation (currently - because of drda limitation), but create=true, which is really where it's limited, is not documented per se there, it's a shared connection Attribute documented on ref/rrefattrib26867.dita.
          And it's an odd location to go into details on this specific case there.

          Perhaps somehow on adminguide\cadminappsclient.html (src/adminguide/cadminappsclient.dita)? Perhaps under the retrieveMessageText entry?

          Or is there somewhere better?

          Show
          Myrna van Lunteren added a comment - [10.5.2 Triage] This issue may have gotten into a confusing state because of David's concerns... Whether the community should find another network connection model than NetworkServer/DerbyClient and/or another protocol than DRDA is a different issue from what we see here - unintuitive current behavior. I think making this a documentation issue makes sense. But where should this get documented? This is a network server/client limitation (currently - because of drda limitation), but create=true, which is really where it's limited, is not documented per se there, it's a shared connection Attribute documented on ref/rrefattrib26867.dita. And it's an odd location to go into details on this specific case there. Perhaps somehow on adminguide\cadminappsclient.html (src/adminguide/cadminappsclient.dita)? Perhaps under the retrieveMessageText entry? Or is there somewhere better?
          Hide
          Myrna van Lunteren added a comment -

          attaching an updated repro - this repro uses derbyclient and correct/current url.
          The repro expects network server to have been started before it's run.
          Note that retrieveMessageText is true by default, so is not really needed in the url for derbyclient.

          Show
          Myrna van Lunteren added a comment - attaching an updated repro - this repro uses derbyclient and correct/current url. The repro expects network server to have been started before it's run. Note that retrieveMessageText is true by default, so is not really needed in the url for derbyclient.
          Hide
          Kim Haase added a comment -

          Let me see if I understand this first ...

          It's only warnings from the server that don't get to the client, right? Not outright errors.

          And this happens whether you're getting the connection programmatically or using the command line (ij)? This seems to be the case when I try it on the command line too.

          The Reference Manual documentation on create=true (http://db.apache.org/derby/docs/dev/ref/rrefattrib26867.html) says,

          "If the database already exists, creates a connection to the existing database and an SQLWarning is issued."

          And further down, rather redundantly,

          "Note: If you specify create=true and the database already exists, an SQLWarning is raised."

          It would probably be helpful to mention that if you are running in client mode, you don't see the warning.

          The Reference Manual does not document the retrieveMessageText or retrieveMessagesFromServerOnGetMessage attributes. The retrieveMessageText attribute is listed in the Admin Guide, in Table 2 of http://db.apache.org/derby/docs/dev/adminguide/cadminappsclient.html; all the other DataSource properties in that table are documented as connection URL attributes in the Reference Manual. The retrieveMessagesFromServerOnGetMessage attribute is mentioned in the issue description but is shown only in two of the demo programs described in the Admin Guide in http://db.apache.org/derby/docs/dev/adminguide/radminsampleprograms.html. (BTW, the paths for all these programs are incorrect.) Are there two attributes or only one? If two, what's the difference? If one, which is the correct name? Should the attribute(s) be documented in the Reference Manual? If so, it should probably be with the notation that only errors are retrieved from the server, not warnings.

          So, action items, the last two of which could be separate issues –

          1) Document warning situation for create=true attribute (Ref Man).
          2) Mention in cadminappsclient topic that retrieveMessageText or whatever it's called retrieves only errors, not warnings.
          3) Document retrieveMessageText or whatever it's called in the Ref Man.
          4) Fix sample program paths in radminsampleprograms topic.

          Show
          Kim Haase added a comment - Let me see if I understand this first ... It's only warnings from the server that don't get to the client, right? Not outright errors. And this happens whether you're getting the connection programmatically or using the command line (ij)? This seems to be the case when I try it on the command line too. The Reference Manual documentation on create=true ( http://db.apache.org/derby/docs/dev/ref/rrefattrib26867.html ) says, "If the database already exists, creates a connection to the existing database and an SQLWarning is issued." And further down, rather redundantly, "Note: If you specify create=true and the database already exists, an SQLWarning is raised." It would probably be helpful to mention that if you are running in client mode, you don't see the warning. The Reference Manual does not document the retrieveMessageText or retrieveMessagesFromServerOnGetMessage attributes. The retrieveMessageText attribute is listed in the Admin Guide, in Table 2 of http://db.apache.org/derby/docs/dev/adminguide/cadminappsclient.html ; all the other DataSource properties in that table are documented as connection URL attributes in the Reference Manual. The retrieveMessagesFromServerOnGetMessage attribute is mentioned in the issue description but is shown only in two of the demo programs described in the Admin Guide in http://db.apache.org/derby/docs/dev/adminguide/radminsampleprograms.html . (BTW, the paths for all these programs are incorrect.) Are there two attributes or only one? If two, what's the difference? If one, which is the correct name? Should the attribute(s) be documented in the Reference Manual? If so, it should probably be with the notation that only errors are retrieved from the server, not warnings. So, action items, the last two of which could be separate issues – 1) Document warning situation for create=true attribute (Ref Man). 2) Mention in cadminappsclient topic that retrieveMessageText or whatever it's called retrieves only errors, not warnings. 3) Document retrieveMessageText or whatever it's called in the Ref Man. 4) Fix sample program paths in radminsampleprograms topic.
          Hide
          Myrna van Lunteren added a comment -

          re retrieveMessageText / retrieveMessagesFromServerOnGetMessage: this is a really old bug, and reflects IBMs db2jcc client, of which there should be no mention in our documentation. Didn't we/you recently scrub the last remnants out?
          Maybe the references should get scrubbed from the sample programs too...But that's another issue.

          The derbyclient equivalent of the long property in the bug report (which value was false by default) is retrieveMessageText. In addition to being much shorter and to the point, its value is 'true' by default.

          I believe the problem is that warnings generated from the passing of the url during the connection attempt cannot be returned to the client. If there is an error, the connection just fails and that will give a client error, I think. Once the connection has been made with retrieveMessageText=true (which is the default) both warnings and errors should get returned.

          Show
          Myrna van Lunteren added a comment - re retrieveMessageText / retrieveMessagesFromServerOnGetMessage: this is a really old bug, and reflects IBMs db2jcc client, of which there should be no mention in our documentation. Didn't we/you recently scrub the last remnants out? Maybe the references should get scrubbed from the sample programs too...But that's another issue. The derbyclient equivalent of the long property in the bug report (which value was false by default) is retrieveMessageText. In addition to being much shorter and to the point, its value is 'true' by default. I believe the problem is that warnings generated from the passing of the url during the connection attempt cannot be returned to the client. If there is an error, the connection just fails and that will give a client error, I think. Once the connection has been made with retrieveMessageText=true (which is the default) both warnings and errors should get returned.
          Hide
          Myrna van Lunteren added a comment -

          And by the way, even with retrieveMessageText=false the warnings should get returned, but you won't get text of the message, just the SQLState.

          Show
          Myrna van Lunteren added a comment - And by the way, even with retrieveMessageText=false the warnings should get returned, but you won't get text of the message, just the SQLState.
          Hide
          Dag H. Wanvik added a comment - - edited

          DERBY-4471 adds a variant of JDBC.assertResultSetMethod which asserts on result set warnings. Currently, this functionaility is disabled when running the tests with the client driver due to this issue (I think - not verified). It would be good to update assertResultSetMethod when this issue is fixed.

          Show
          Dag H. Wanvik added a comment - - edited DERBY-4471 adds a variant of JDBC.assertResultSetMethod which asserts on result set warnings. Currently, this functionaility is disabled when running the tests with the client driver due to this issue (I think - not verified). It would be good to update assertResultSetMethod when this issue is fixed.
          Hide
          Kim Haase added a comment -

          This issue is resolved as a result of the fix to DERBY-5191, documenting the retrieveMessageText URL attribute.

          Show
          Kim Haase added a comment - This issue is resolved as a result of the fix to DERBY-5191 , documenting the retrieveMessageText URL attribute.
          Hide
          Kim Haase added a comment -

          Fixed as a result of DERBY-5191 fixes. Changes appeared in 10.8.2 documentation, so closing.

          Show
          Kim Haase added a comment - Fixed as a result of DERBY-5191 fixes. Changes appeared in 10.8.2 documentation, so closing.
          Hide
          Knut Anders Hatlen added a comment -

          [bulk update: close all resolved issues that haven't had any activity the last year]

          Show
          Knut Anders Hatlen added a comment - [bulk update: close all resolved issues that haven't had any activity the last year]

            People

            • Assignee:
              Kim Haase
              Reporter:
              Mamta A. Satoor
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development