From davecramer at gmail.com Wed Feb 17 10:53:38 2021 From: davecramer at gmail.com (Dave Cramer) Date: Wed, 17 Feb 2021 05:53:38 -0500 Subject: closeOnCompletion Message-ID: Interesting situation. If we have an open statement with open resultsets and call closeOnCompletion and then execute the statement a second time the statement will throw an already closed exception since the spec says that executing a statement a second time closes any open resultsets. Closing said resultsets ends up closing the statement. I'm just confirming that this is the intended behaviour. Seems about right since if you set closeOnCompletion you would not expect to re-use the statement. Dave Cramer From mark at lawinegevaar.nl Wed Feb 17 12:19:23 2021 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Wed, 17 Feb 2021 13:19:23 +0100 Subject: closeOnCompletion In-Reply-To: References: Message-ID: <5f8f075a9f4c8c36f5e8781dad661645@lawinegevaar.nl> On 2021-02-17 11:53, Dave Cramer wrote: > Interesting situation. > > If we have an open statement with open resultsets and call > closeOnCompletion and then execute the statement a second time the > statement will throw an already closed exception since the spec says > that > executing a statement a second time closes any open resultsets. Closing > said resultsets ends up closing the statement. > > I'm just confirming that this is the intended behaviour. Seems about > right > since if you set closeOnCompletion you would not expect to re-use the > statement. Logically, yes, I think this is how it is supposed to work. If you call closeOnCompletion, you signal that you intended to abandon the statement after processing, so if you then go and try to use the statement any way, you're doing something wrong. Mark From mark at lawinegevaar.nl Wed Feb 17 13:24:26 2021 From: mark at lawinegevaar.nl (Mark Rotteveel) Date: Wed, 17 Feb 2021 14:24:26 +0100 Subject: closeOnCompletion In-Reply-To: <5f8f075a9f4c8c36f5e8781dad661645@lawinegevaar.nl> References: <5f8f075a9f4c8c36f5e8781dad661645@lawinegevaar.nl> Message-ID: <3cc8ece171f095808c2eb043a78cd091@lawinegevaar.nl> On 2021-02-17 13:19, Mark Rotteveel wrote: > On 2021-02-17 11:53, Dave Cramer wrote: >> Interesting situation. >> >> If we have an open statement with open resultsets and call >> closeOnCompletion and then execute the statement a second time the >> statement will throw an already closed exception since the spec says >> that >> executing a statement a second time closes any open resultsets. >> Closing >> said resultsets ends up closing the statement. >> >> I'm just confirming that this is the intended behaviour. Seems about >> right >> since if you set closeOnCompletion you would not expect to re-use the >> statement. > > Logically, yes, I think this is how it is supposed to work. If you > call closeOnCompletion, you signal that you intended to abandon the > statement after processing, so if you then go and try to use the > statement any way, you're doing something wrong. I also posted an answer to this effect at https://stackoverflow.com/a/66242121/466862 However, thinking some more about it, I'm wondering if maybe there is something missing in the documentation of closeOnCompletion. I have always assumed that it means that the statement must be closed when execution completes, but now I'm wondering if it actually means that calling close() will delay the actual close of the statement until after execution (processing all results) is complete. In other words: maybe closeOnCompletion shouldn't do anything until you call close(), at which point it will delay the actual close until you have processed all results. Mark From davecramer at gmail.com Wed Feb 17 13:35:20 2021 From: davecramer at gmail.com (Dave Cramer) Date: Wed, 17 Feb 2021 08:35:20 -0500 Subject: closeOnCompletion In-Reply-To: <3cc8ece171f095808c2eb043a78cd091@lawinegevaar.nl> References: <5f8f075a9f4c8c36f5e8781dad661645@lawinegevaar.nl> <3cc8ece171f095808c2eb043a78cd091@lawinegevaar.nl> Message-ID: On Wed, 17 Feb 2021 at 08:25, Mark Rotteveel wrote: > On 2021-02-17 13:19, Mark Rotteveel wrote: > > On 2021-02-17 11:53, Dave Cramer wrote: > >> Interesting situation. > >> > >> If we have an open statement with open resultsets and call > >> closeOnCompletion and then execute the statement a second time the > >> statement will throw an already closed exception since the spec says > >> that > >> executing a statement a second time closes any open resultsets. > >> Closing > >> said resultsets ends up closing the statement. > >> > >> I'm just confirming that this is the intended behaviour. Seems about > >> right > >> since if you set closeOnCompletion you would not expect to re-use the > >> statement. > > > > Logically, yes, I think this is how it is supposed to work. If you > > call closeOnCompletion, you signal that you intended to abandon the > > statement after processing, so if you then go and try to use the > > statement any way, you're doing something wrong. > > I also posted an answer to this effect at > https://stackoverflow.com/a/66242121/466862 > > However, thinking some more about it, I'm wondering if maybe there is > something missing in the documentation of closeOnCompletion. I have > always assumed that it means that the statement must be closed when > execution completes, but now I'm wondering if it actually means that > calling close() will delay the actual close of the statement until after > execution (processing all results) is complete. In other words: maybe > closeOnCompletion shouldn't do anything until you call close(), at which > point it will delay the actual close until you have processed all > results. > > In this case the results are being closed as a result of executing the statement again. I do not think that is at odds with the documentation. That said the docs are certainly not explicit. It does say that calling closeOnCompletion affects the current statement and any dependent result sets. Dave > > Mark > From filipe.silva at oracle.com Wed Feb 17 17:13:16 2021 From: filipe.silva at oracle.com (Filipe Silva) Date: Wed, 17 Feb 2021 17:13:16 +0000 Subject: closeOnCompletion In-Reply-To: References: Message-ID: <49dea793-7688-88f8-a0da-2edc2e7a7161@oracle.com> On 17/02/21 10:53, Dave Cramer wrote: > Interesting situation. > > If we have an open statement with open resultsets and call > closeOnCompletion and then execute the statement a second time the > statement will throw an already closed exception since the spec says that > executing a statement a second time closes any open resultsets. Closing > said resultsets ends up closing the statement. > > I'm just confirming that this is the intended behaviour. Seems about right > since if you set closeOnCompletion you would not expect to re-use the > statement. > > Dave Cramer No, I don't think it is supposed to work like this. "Completion" means that the user is done with the ResultSet(s) and explicitely calls close() on it/them. Successive executions do close previously opened ResultSets but closing those ResultSets implicitely (by re-executing) do not close the Statement. The documentation makes it clear when it says "a call to |closeOnCompletion| does effect both the *subsequent execution of statements*, (...)". There would be no "subsequent execution of statements" if the behavior was the one you described. Filipe Silva -- Oracle Filipe Silva, Senior Software Developer Mobile: +351.91.009.2110 MySQL Middleware and Clients Oracle Portugal, Lagoas Park, Edif?cio N.? 8, 2740-244 Porto Salvo From davecramer at gmail.com Wed Feb 17 17:34:41 2021 From: davecramer at gmail.com (Dave Cramer) Date: Wed, 17 Feb 2021 12:34:41 -0500 Subject: closeOnCompletion In-Reply-To: <49dea793-7688-88f8-a0da-2edc2e7a7161@oracle.com> References: <49dea793-7688-88f8-a0da-2edc2e7a7161@oracle.com> Message-ID: On Wed, 17 Feb 2021 at 12:13, Filipe Silva wrote: > On 17/02/21 10:53, Dave Cramer wrote: > > Interesting situation. > > > > If we have an open statement with open resultsets and call > > closeOnCompletion and then execute the statement a second time the > > statement will throw an already closed exception since the spec says that > > executing a statement a second time closes any open resultsets. Closing > > said resultsets ends up closing the statement. > > > > I'm just confirming that this is the intended behaviour. Seems about > right > > since if you set closeOnCompletion you would not expect to re-use the > > statement. > > > > Dave Cramer > No, I don't think it is supposed to work like this. "Completion" means > that the user is done with the ResultSet(s) and explicitely calls > close() on it/them. > > Successive executions do close previously opened ResultSets but closing > those ResultSets implicitely (by re-executing) do not close the > Statement. The documentation makes it clear when it says "a call to > |closeOnCompletion| does effect both the *subsequent execution of > statements*, (...)". There would be no "subsequent execution of > statements" if the behavior was the one you described. > Well interestingly I'm told that the Oracle driver does close the statement on subsequent execution. Either way I'm not sure I agree with the inference. Now we have to debate the word execution. Is calling the method an execution or is completing the call an execution ? Dave Cramer > > From lance.andersen at oracle.com Wed Feb 17 17:52:52 2021 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 17 Feb 2021 17:52:52 +0000 Subject: closeOnCompletion In-Reply-To: References: <49dea793-7688-88f8-a0da-2edc2e7a7161@oracle.com> Message-ID: I will have to go dig back through my email archive as this was first discussed in 2009. The overall intent was to deal with code similar to: ---------------------- ResultSet rs = foo(); while(rs.next() { /*do something */ } rs.close(); public ResultSet foo() { Statement stmt = con.createStatement(); stmt.closeOnCompletion(); ResultSet rs = stmt.executeQuery(aQuery); return rs } ------------------ We did spend a lot of time on this back in 2009 and took quite a bit of time to reach agreement on the current wording. However, it does look like there is the potential for some additional word smithing. Best Lance On Feb 17, 2021, at 12:34 PM, Dave Cramer > wrote: On Wed, 17 Feb 2021 at 12:13, Filipe Silva > wrote: On 17/02/21 10:53, Dave Cramer wrote: Interesting situation. If we have an open statement with open resultsets and call closeOnCompletion and then execute the statement a second time the statement will throw an already closed exception since the spec says that executing a statement a second time closes any open resultsets. Closing said resultsets ends up closing the statement. I'm just confirming that this is the intended behaviour. Seems about right since if you set closeOnCompletion you would not expect to re-use the statement. Dave Cramer No, I don't think it is supposed to work like this. "Completion" means that the user is done with the ResultSet(s) and explicitely calls close() on it/them. Successive executions do close previously opened ResultSets but closing those ResultSets implicitely (by re-executing) do not close the Statement. The documentation makes it clear when it says "a call to |closeOnCompletion| does effect both the *subsequent execution of statements*, (...)". There would be no "subsequent execution of statements" if the behavior was the one you described. Well interestingly I'm told that the Oracle driver does close the statement on subsequent execution. Either way I'm not sure I agree with the inference. Now we have to debate the word execution. Is calling the method an execution or is completing the call an execution ? Dave Cramer From douglas.surber at oracle.com Wed Feb 17 18:32:54 2021 From: douglas.surber at oracle.com (Douglas Surber) Date: Wed, 17 Feb 2021 18:32:54 +0000 Subject: closeOnCompletion In-Reply-To: References: <49dea793-7688-88f8-a0da-2edc2e7a7161@oracle.com> , Message-ID: I wrote the original proposal. The intent was to handle the case Lance described. It was not intended to allow multiple executions of the Statement. So while the language may not be as clear as it needs to be, the case Filipe described should throw on the second execution of the Statement. At least that was my intent. Douglas ________________________________ From: jdbc-spec-discuss on behalf of Lance Andersen Sent: Wednesday, February 17, 2021 9:52 AM To: Dave Cramer Cc: Filipe Silva ; jdbc-spec-discuss at openjdk.java.net Subject: Re: closeOnCompletion I will have to go dig back through my email archive as this was first discussed in 2009. The overall intent was to deal with code similar to: ---------------------- ResultSet rs = foo(); while(rs.next() { /*do something */ } rs.close(); public ResultSet foo() { Statement stmt = con.createStatement(); stmt.closeOnCompletion(); ResultSet rs = stmt.executeQuery(aQuery); return rs } ------------------ We did spend a lot of time on this back in 2009 and took quite a bit of time to reach agreement on the current wording. However, it does look like there is the potential for some additional word smithing. Best Lance On Feb 17, 2021, at 12:34 PM, Dave Cramer > wrote: On Wed, 17 Feb 2021 at 12:13, Filipe Silva > wrote: On 17/02/21 10:53, Dave Cramer wrote: Interesting situation. If we have an open statement with open resultsets and call closeOnCompletion and then execute the statement a second time the statement will throw an already closed exception since the spec says that executing a statement a second time closes any open resultsets. Closing said resultsets ends up closing the statement. I'm just confirming that this is the intended behaviour. Seems about right since if you set closeOnCompletion you would not expect to re-use the statement. Dave Cramer No, I don't think it is supposed to work like this. "Completion" means that the user is done with the ResultSet(s) and explicitely calls close() on it/them. Successive executions do close previously opened ResultSets but closing those ResultSets implicitely (by re-executing) do not close the Statement. The documentation makes it clear when it says "a call to |closeOnCompletion| does effect both the *subsequent execution of statements*, (...)". There would be no "subsequent execution of statements" if the behavior was the one you described. Well interestingly I'm told that the Oracle driver does close the statement on subsequent execution. Either way I'm not sure I agree with the inference. Now we have to debate the word execution. Is calling the method an execution or is completing the call an execution ? Dave Cramer From davecramer at gmail.com Wed Feb 17 18:38:20 2021 From: davecramer at gmail.com (Dave Cramer) Date: Wed, 17 Feb 2021 13:38:20 -0500 Subject: closeOnCompletion In-Reply-To: References: <49dea793-7688-88f8-a0da-2edc2e7a7161@oracle.com> Message-ID: On Wed, 17 Feb 2021 at 13:33, Douglas Surber wrote: > I wrote the original proposal. The intent was to handle the case Lance > described. It was not intended to allow multiple executions of the > Statement. So while the language may not be as clear as it needs to be, the > case Filipe described should throw on the second execution of the > Statement. At least that was my intent. > > Well there's enough hints in the wording to figure that out, but they are just hints. We (postgres) are going to implement it in such a way that the statement will not be executed twice Dave > Douglas > ------------------------------ > *From:* jdbc-spec-discuss on > behalf of Lance Andersen > *Sent:* Wednesday, February 17, 2021 9:52 AM > *To:* Dave Cramer > *Cc:* Filipe Silva ; > jdbc-spec-discuss at openjdk.java.net > *Subject:* Re: closeOnCompletion > > I will have to go dig back through my email archive as this was first > discussed in 2009. > > > The overall intent was to deal with code similar to: > > ---------------------- > ResultSet rs = foo(); > while(rs.next() { > /*do something */ > } > rs.close(); > > public ResultSet foo() { > > Statement stmt = con.createStatement(); > stmt.closeOnCompletion(); > ResultSet rs = stmt.executeQuery(aQuery); > return rs > > } > ------------------ > > > We did spend a lot of time on this back in 2009 and took quite a bit of > time to reach agreement on the current wording. However, it does look > like there is the potential for some additional word smithing. > > Best > Lance > > > > On Feb 17, 2021, at 12:34 PM, Dave Cramer davecramer at gmail.com>> wrote: > > On Wed, 17 Feb 2021 at 12:13, Filipe Silva > wrote: > > On 17/02/21 10:53, Dave Cramer wrote: > Interesting situation. > > If we have an open statement with open resultsets and call > closeOnCompletion and then execute the statement a second time the > statement will throw an already closed exception since the spec says that > executing a statement a second time closes any open resultsets. Closing > said resultsets ends up closing the statement. > > I'm just confirming that this is the intended behaviour. Seems about > right > since if you set closeOnCompletion you would not expect to re-use the > statement. > > Dave Cramer > No, I don't think it is supposed to work like this. "Completion" means > that the user is done with the ResultSet(s) and explicitely calls > close() on it/them. > > Successive executions do close previously opened ResultSets but closing > those ResultSets implicitely (by re-executing) do not close the > Statement. The documentation makes it clear when it says "a call to > |closeOnCompletion| does effect both the *subsequent execution of > statements*, (...)". There would be no "subsequent execution of > statements" if the behavior was the one you described. > > > Well interestingly I'm told that the Oracle driver does close the statement > on subsequent execution. > > Either way I'm not sure I agree with the inference. Now we have to debate > the word execution. Is calling the method an execution or is completing the > call an execution ? > > Dave Cramer > > From filipe.silva at oracle.com Wed Feb 17 18:55:10 2021 From: filipe.silva at oracle.com (Filipe Silva) Date: Wed, 17 Feb 2021 18:55:10 +0000 Subject: closeOnCompletion In-Reply-To: References: <49dea793-7688-88f8-a0da-2edc2e7a7161@oracle.com> Message-ID: Well, looks strange to me. I explain why in the an answer I wrote in StackOverflow (https://stackoverflow.com/questions/66241480/jdbc-statement-closeoncompletion-should-close-statement-on-next-execution/66248074#66248074). Moreover, IMO, allowing re-executions doesn't conflict with the use case below and it allows more. Regards, Filipe On 17/02/21 18:38, Dave Cramer wrote: > > > On Wed, 17 Feb 2021 at 13:33, Douglas Surber > > wrote: > > I wrote the original proposal. The intent was to handle the case > Lance described. It was not intended to allow multiple executions > of the Statement. So while the language may not be as clear as it > needs to be, the case Filipe described should throw on the second > execution of the Statement. At least that was my intent. > > > Well there's enough hints in the wording to figure that out, but they > are just hints. > We (postgres) are going to implement it in such a way that the > statement will not be executed twice > > Dave > > Douglas > ------------------------------------------------------------------------ > *From:* jdbc-spec-discuss > on behalf of > Lance Andersen > > *Sent:* Wednesday, February 17, 2021 9:52 AM > *To:* Dave Cramer > > *Cc:* Filipe Silva >; > jdbc-spec-discuss at openjdk.java.net > > > > *Subject:* Re: closeOnCompletion > I will have to go dig back through my email archive as this was > first discussed in 2009. > > > The overall intent was to deal with code similar to: > > ---------------------- > ResultSet rs = foo(); > ?while(rs.next() { > ???? /*do something */ > } > rs.close(); > > public ResultSet foo() { > > ?? Statement stmt = con.createStatement(); > ?? stmt.closeOnCompletion(); > ?? ResultSet rs = stmt.executeQuery(aQuery); > ?? return rs > > } > ------------------ > > > We did spend a lot of time on this back in 2009 and took quite a > bit of time to reach agreement on the current wording.? However, > it does? look like there is the potential for some additional word > smithing. > > Best > Lance > > > > On Feb 17, 2021, at 12:34 PM, Dave Cramer >> wrote: > > On Wed, 17 Feb 2021 at 12:13, Filipe Silva > >> wrote: > > On 17/02/21 10:53, Dave Cramer wrote: > Interesting situation. > > If we have an open statement with open resultsets and call > closeOnCompletion and then execute the statement a second time the > statement will throw an already closed exception since the spec > says that > executing a statement a second time closes any open resultsets. > Closing > said resultsets ends up closing the statement. > > I'm just confirming that this is the intended behaviour. Seems about > right > since if you set closeOnCompletion you would not expect to re-use the > statement. > > Dave Cramer > No, I don't think it is supposed to work like this. "Completion" means > that the user is done with the ResultSet(s) and explicitely calls > close() on it/them. > > Successive executions do close previously opened ResultSets but > closing > those ResultSets implicitely (by re-executing) do not close the > Statement. The documentation makes it clear when it says "a call to > |closeOnCompletion| does effect both the *subsequent execution of > statements*, (...)". There would be no "subsequent execution of > statements" if the behavior was the one you described. > > > Well interestingly I'm told that the Oracle driver does close the > statement > on subsequent execution. > > Either way I'm not sure I agree with the inference. Now we have to > debate > the word execution. Is calling the method an execution or is > completing the > call an execution ? > > Dave Cramer > -- Oracle Filipe Silva, Senior Software Developer Mobile: +351.91.009.2110 MySQL Middleware and Clients Oracle Portugal, Lagoas Park, Edif?cio N.? 8, 2740-244 Porto Salvo From douglas.surber at oracle.com Wed Feb 17 19:03:07 2021 From: douglas.surber at oracle.com (Douglas Surber) Date: Wed, 17 Feb 2021 19:03:07 +0000 Subject: closeOnCompletion In-Reply-To: References: <49dea793-7688-88f8-a0da-2edc2e7a7161@oracle.com> , Message-ID: As I said I wrote the original proposal and what I intended and what the EG discussed at the time at least implicitly was that closing the open ResultSet would close the Statement and that no subsequent execution was possible. No this wasn't spelled out in the discussion. It was clearly the intent as the purpose of the method was to handle the case Lance described. Maybe the language is unclear but I don't think that would justify expanding the behavior of the method to cover your use case. The goal is to support a specific use case. Any change to the spec should be to more clearly state how that use case is supported, not to expand the meaning to support additional use cases, especially a use case that has never come up in practice. Douglas ________________________________ From: Filipe Silva Sent: Wednesday, February 17, 2021 10:55 AM To: Dave Cramer ; Douglas Surber Cc: Lance Andersen ; jdbc-spec-discuss at openjdk.java.net Subject: Re: closeOnCompletion Well, looks strange to me. I explain why in the an answer I wrote in StackOverflow (https://stackoverflow.com/questions/66241480/jdbc-statement-closeoncompletion-should-close-statement-on-next-execution/66248074#66248074). Moreover, IMO, allowing re-executions doesn't conflict with the use case below and it allows more. Regards, Filipe On 17/02/21 18:38, Dave Cramer wrote: On Wed, 17 Feb 2021 at 13:33, Douglas Surber > wrote: I wrote the original proposal. The intent was to handle the case Lance described. It was not intended to allow multiple executions of the Statement. So while the language may not be as clear as it needs to be, the case Filipe described should throw on the second execution of the Statement. At least that was my intent. Well there's enough hints in the wording to figure that out, but they are just hints. We (postgres) are going to implement it in such a way that the statement will not be executed twice Dave Douglas ________________________________ From: jdbc-spec-discuss > on behalf of Lance Andersen > Sent: Wednesday, February 17, 2021 9:52 AM To: Dave Cramer > Cc: Filipe Silva >; jdbc-spec-discuss at openjdk.java.net > Subject: Re: closeOnCompletion I will have to go dig back through my email archive as this was first discussed in 2009. The overall intent was to deal with code similar to: ---------------------- ResultSet rs = foo(); while(rs.next() { /*do something */ } rs.close(); public ResultSet foo() { Statement stmt = con.createStatement(); stmt.closeOnCompletion(); ResultSet rs = stmt.executeQuery(aQuery); return rs } ------------------ We did spend a lot of time on this back in 2009 and took quite a bit of time to reach agreement on the current wording. However, it does look like there is the potential for some additional word smithing. Best Lance On Feb 17, 2021, at 12:34 PM, Dave Cramer >> wrote: On Wed, 17 Feb 2021 at 12:13, Filipe Silva >> wrote: On 17/02/21 10:53, Dave Cramer wrote: Interesting situation. If we have an open statement with open resultsets and call closeOnCompletion and then execute the statement a second time the statement will throw an already closed exception since the spec says that executing a statement a second time closes any open resultsets. Closing said resultsets ends up closing the statement. I'm just confirming that this is the intended behaviour. Seems about right since if you set closeOnCompletion you would not expect to re-use the statement. Dave Cramer No, I don't think it is supposed to work like this. "Completion" means that the user is done with the ResultSet(s) and explicitely calls close() on it/them. Successive executions do close previously opened ResultSets but closing those ResultSets implicitely (by re-executing) do not close the Statement. The documentation makes it clear when it says "a call to |closeOnCompletion| does effect both the *subsequent execution of statements*, (...)". There would be no "subsequent execution of statements" if the behavior was the one you described. Well interestingly I'm told that the Oracle driver does close the statement on subsequent execution. Either way I'm not sure I agree with the inference. Now we have to debate the word execution. Is calling the method an execution or is completing the call an execution ? Dave Cramer -- [Oracle] Filipe Silva, Senior Software Developer Mobile: +351.91.009.2110 MySQL Middleware and Clients Oracle Portugal, Lagoas Park, Edif?cio N.? 8, 2740-244 Porto Salvo From filipe.silva at oracle.com Wed Feb 17 19:14:42 2021 From: filipe.silva at oracle.com (Filipe Silva) Date: Wed, 17 Feb 2021 19:14:42 +0000 Subject: closeOnCompletion In-Reply-To: References: <49dea793-7688-88f8-a0da-2edc2e7a7161@oracle.com> Message-ID: Hi Douglas, Wait, this is not the question here, there is no doubt that closing the result sets closes the statement. The question is whether a statement with `closeOnCompletion` and an active results set (not closed yet) can be re-executed or not. In different words, implicit closing of open result sets on next statement execution triggers `closeOnCompletion` and closes the statement or should it execute? Regards, Filipe On 17/02/21 19:03, Douglas Surber wrote: > As I said I wrote the original proposal and what I intended and what > the EG discussed at the time at least implicitly was that closing the > open ResultSet would close the Statement and that no subsequent > execution was possible. No this wasn't spelled out in the discussion. > It was clearly the intent as the purpose of the method was to handle > the case Lance described. > > Maybe the language is unclear but I don't think that would justify > expanding the behavior of the method to cover your use case. The goal > is to support a specific use case. Any change to the spec should be to > more clearly state how that use case is supported, not to expand the > meaning to support additional use cases, especially a use case that > has never come up in practice. > > Douglas > ------------------------------------------------------------------------ > *From:* Filipe Silva > *Sent:* Wednesday, February 17, 2021 10:55 AM > *To:* Dave Cramer ; Douglas Surber > > *Cc:* Lance Andersen ; > jdbc-spec-discuss at openjdk.java.net > *Subject:* Re: closeOnCompletion > > Well, looks strange to me. I explain why in the an answer I wrote in > StackOverflow > (https://stackoverflow.com/questions/66241480/jdbc-statement-closeoncompletion-should-close-statement-on-next-execution/66248074#66248074). > > Moreover, IMO, allowing re-executions doesn't conflict with the use > case below and it allows more. > > Regards, > Filipe > > On 17/02/21 18:38, Dave Cramer wrote: >> >> >> On Wed, 17 Feb 2021 at 13:33, Douglas Surber >> > wrote: >> >> I wrote the original proposal. The intent was to handle the case >> Lance described. It was not intended to allow multiple executions >> of the Statement. So while the language may not be as clear as it >> needs to be, the case Filipe described should throw on the second >> execution of the Statement. At least that was my intent. >> >> >> Well there's enough hints in the wording to figure that out, but they >> are just hints. >> We (postgres) are going to implement it in such a way that the >> statement will not be executed twice >> >> Dave >> >> Douglas >> ------------------------------------------------------------------------ >> *From:* jdbc-spec-discuss >> > > on behalf of >> Lance Andersen > > >> *Sent:* Wednesday, February 17, 2021 9:52 AM >> *To:* Dave Cramer > > >> *Cc:* Filipe Silva > >; >> jdbc-spec-discuss at openjdk.java.net >> >> > > >> *Subject:* Re: closeOnCompletion >> I will have to go dig back through my email archive as this was >> first discussed in 2009. >> >> >> The overall intent was to deal with code similar to: >> >> ---------------------- >> ResultSet rs = foo(); >> ?while(rs.next() { >> ???? /*do something */ >> } >> rs.close(); >> >> public ResultSet foo() { >> >> ?? Statement stmt = con.createStatement(); >> ?? stmt.closeOnCompletion(); >> ?? ResultSet rs = stmt.executeQuery(aQuery); >> ?? return rs >> >> } >> ------------------ >> >> >> We did spend a lot of time on this back in 2009 and took quite a >> bit of time to reach agreement on the current wording.? However, >> it does? look like there is the potential for some additional >> word smithing. >> >> Best >> Lance >> >> >> >> On Feb 17, 2021, at 12:34 PM, Dave Cramer > > >> wrote: >> >> On Wed, 17 Feb 2021 at 12:13, Filipe Silva >> > > >> wrote: >> >> On 17/02/21 10:53, Dave Cramer wrote: >> Interesting situation. >> >> If we have an open statement with open resultsets and call >> closeOnCompletion and then execute the statement a second time the >> statement will throw an already closed exception since the spec >> says that >> executing a statement a second time closes any open resultsets. >> Closing >> said resultsets ends up closing the statement. >> >> I'm just confirming that this is the intended behaviour. Seems about >> right >> since if you set closeOnCompletion you would not expect to re-use the >> statement. >> >> Dave Cramer >> No, I don't think it is supposed to work like this. "Completion" >> means >> that the user is done with the ResultSet(s) and explicitely calls >> close() on it/them. >> >> Successive executions do close previously opened ResultSets but >> closing >> those ResultSets implicitely (by re-executing) do not close the >> Statement. The documentation makes it clear when it says "a call to >> |closeOnCompletion| does effect both the *subsequent execution of >> statements*, (...)". There would be no "subsequent execution of >> statements" if the behavior was the one you described. >> >> >> Well interestingly I'm told that the Oracle driver does close the >> statement >> on subsequent execution. >> >> Either way I'm not sure I agree with the inference. Now we have >> to debate >> the word execution. Is calling the method an execution or is >> completing the >> call an execution ? >> >> Dave Cramer >> > -- > > Oracle > Filipe Silva, Senior Software Developer > Mobile: +351.91.009.2110 > MySQL Middleware and Clients > Oracle Portugal, Lagoas Park, Edif?cio N.? 8, 2740-244 Porto Salvo > > -- Oracle Filipe Silva, Senior Software Developer Mobile: +351.91.009.2110 MySQL Middleware and Clients Oracle Portugal, Lagoas Park, Edif?cio N.? 8, 2740-244 Porto Salvo From lance.andersen at oracle.com Wed Feb 17 19:25:52 2021 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 17 Feb 2021 19:25:52 +0000 Subject: closeOnCompletion In-Reply-To: References: <49dea793-7688-88f8-a0da-2edc2e7a7161@oracle.com> Message-ID: Hi Filipe, As Douglas points out at the time of the discussion, the JDBC EG consensus was the Statement would be closed. If applications did not want this behavior they should not call Statement::closeOnCompletion and if they were not sure if the method had been invoked, they could always call Statement::isCloseOnCompletion to make a decision programatically. This area as you are aware is messy enough and the intent was to address a common use case which lead to common issues for applications and not further complicate things. HTH Best, Lance On Feb 17, 2021, at 2:14 PM, Filipe Silva > wrote: Hi Douglas, Wait, this is not the question here, there is no doubt that closing the result sets closes the statement. The question is whether a statement with `closeOnCompletion` and an active results set (not closed yet) can be re-executed or not. In different words, implicit closing of open result sets on next statement execution triggers `closeOnCompletion` and closes the statement or should it execute? Regards, Filipe On 17/02/21 19:03, Douglas Surber wrote: As I said I wrote the original proposal and what I intended and what the EG discussed at the time at least implicitly was that closing the open ResultSet would close the Statement and that no subsequent execution was possible. No this wasn't spelled out in the discussion. It was clearly the intent as the purpose of the method was to handle the case Lance described. Maybe the language is unclear but I don't think that would justify expanding the behavior of the method to cover your use case. The goal is to support a specific use case. Any change to the spec should be to more clearly state how that use case is supported, not to expand the meaning to support additional use cases, especially a use case that has never come up in practice. Douglas ________________________________ From: Filipe Silva Sent: Wednesday, February 17, 2021 10:55 AM To: Dave Cramer ; Douglas Surber Cc: Lance Andersen ; jdbc-spec-discuss at openjdk.java.net Subject: Re: closeOnCompletion Well, looks strange to me. I explain why in the an answer I wrote in StackOverflow (https://stackoverflow.com/questions/66241480/jdbc-statement-closeoncompletion-should-close-statement-on-next-execution/66248074#66248074). Moreover, IMO, allowing re-executions doesn't conflict with the use case below and it allows more. Regards, Filipe On 17/02/21 18:38, Dave Cramer wrote: On Wed, 17 Feb 2021 at 13:33, Douglas Surber > wrote: I wrote the original proposal. The intent was to handle the case Lance described. It was not intended to allow multiple executions of the Statement. So while the language may not be as clear as it needs to be, the case Filipe described should throw on the second execution of the Statement. At least that was my intent. Well there's enough hints in the wording to figure that out, but they are just hints. We (postgres) are going to implement it in such a way that the statement will not be executed twice Dave Douglas ________________________________ From: jdbc-spec-discuss > on behalf of Lance Andersen > Sent: Wednesday, February 17, 2021 9:52 AM To: Dave Cramer > Cc: Filipe Silva >; jdbc-spec-discuss at openjdk.java.net > Subject: Re: closeOnCompletion I will have to go dig back through my email archive as this was first discussed in 2009. The overall intent was to deal with code similar to: ---------------------- ResultSet rs = foo(); while(rs.next() { /*do something */ } rs.close(); public ResultSet foo() { Statement stmt = con.createStatement(); stmt.closeOnCompletion(); ResultSet rs = stmt.executeQuery(aQuery); return rs } ------------------ We did spend a lot of time on this back in 2009 and took quite a bit of time to reach agreement on the current wording. However, it does look like there is the potential for some additional word smithing. Best Lance On Feb 17, 2021, at 12:34 PM, Dave Cramer >> wrote: On Wed, 17 Feb 2021 at 12:13, Filipe Silva >> wrote: On 17/02/21 10:53, Dave Cramer wrote: Interesting situation. If we have an open statement with open resultsets and call closeOnCompletion and then execute the statement a second time the statement will throw an already closed exception since the spec says that executing a statement a second time closes any open resultsets. Closing said resultsets ends up closing the statement. I'm just confirming that this is the intended behaviour. Seems about right since if you set closeOnCompletion you would not expect to re-use the statement. Dave Cramer No, I don't think it is supposed to work like this. "Completion" means that the user is done with the ResultSet(s) and explicitely calls close() on it/them. Successive executions do close previously opened ResultSets but closing those ResultSets implicitely (by re-executing) do not close the Statement. The documentation makes it clear when it says "a call to |closeOnCompletion| does effect both the *subsequent execution of statements*, (...)". There would be no "subsequent execution of statements" if the behavior was the one you described. Well interestingly I'm told that the Oracle driver does close the statement on subsequent execution. Either way I'm not sure I agree with the inference. Now we have to debate the word execution. Is calling the method an execution or is completing the call an execution ? Dave Cramer -- [Oracle] Filipe Silva, Senior Software Developer Mobile: +351.91.009.2110 MySQL Middleware and Clients Oracle Portugal, Lagoas Park, Edif?cio N.? 8, 2740-244 Porto Salvo -- [Oracle] Filipe Silva, Senior Software Developer Mobile: +351.91.009.2110 MySQL Middleware and Clients Oracle Portugal, Lagoas Park, Edif?cio N.? 8, 2740-244 Porto Salvo From jorsol at gmail.com Wed Feb 17 19:43:46 2021 From: jorsol at gmail.com (=?UTF-8?Q?Jorge_Sol=C3=B3rzano?=) Date: Wed, 17 Feb 2021 20:43:46 +0100 Subject: closeOnCompletion In-Reply-To: References: <49dea793-7688-88f8-a0da-2edc2e7a7161@oracle.com> Message-ID: This is indeed what we (postgres driver) are looking for, to know the intent of closeOnCompletion, this might be a little confusing as the current wording is a bit unclear about it, but now it's perfectly clear the intent with the example provided, it would be a nice addition to the spec to clearly state that use case. Regards, Jorge On Wed, Feb 17, 2021 at 8:26 PM Lance Andersen wrote: > Hi Filipe, > > As Douglas points out at the time of the discussion, the JDBC EG > consensus was the Statement would be closed. If applications did not want > this behavior they should not call Statement::closeOnCompletion and if they > were not sure if the method had been invoked, they could always call > Statement::isCloseOnCompletion to make a decision programatically. > > This area as you are aware is messy enough and the intent was to address a > common use case which lead to common issues for applications and not > further complicate things. > > HTH > > Best, > Lance > > On Feb 17, 2021, at 2:14 PM, Filipe Silva filipe.silva at oracle.com>> wrote: > > Hi Douglas, > > Wait, this is not the question here, there is no doubt that closing the > result sets closes the statement. The question is whether a statement with > `closeOnCompletion` and an active results set (not closed yet) can be > re-executed or not. In different words, implicit closing of open result > sets on next statement execution triggers `closeOnCompletion` and closes > the statement or should it execute? > > Regards, > Filipe > > > On 17/02/21 19:03, Douglas Surber wrote: > As I said I wrote the original proposal and what I intended and what the > EG discussed at the time at least implicitly was that closing the open > ResultSet would close the Statement and that no subsequent execution was > possible. No this wasn't spelled out in the discussion. It was clearly the > intent as the purpose of the method was to handle the case Lance described. > > Maybe the language is unclear but I don't think that would justify > expanding the behavior of the method to cover your use case. The goal is to > support a specific use case. Any change to the spec should be to more > clearly state how that use case is supported, not to expand the meaning to > support additional use cases, especially a use case that has never come up > in practice. > > Douglas > ________________________________ > From: Filipe Silva filipe.silva at oracle.com> > Sent: Wednesday, February 17, 2021 10:55 AM > To: Dave Cramer ; > Douglas Surber douglas.surber at oracle.com> > Cc: Lance Andersen lance.andersen at oracle.com>; jdbc-spec-discuss at openjdk.java.net jdbc-spec-discuss at openjdk.java.net> > > Subject: Re: closeOnCompletion > > Well, looks strange to me. I explain why in the an answer I wrote in > StackOverflow ( > https://stackoverflow.com/questions/66241480/jdbc-statement-closeoncompletion-should-close-statement-on-next-execution/66248074#66248074 > ). > Moreover, IMO, allowing re-executions doesn't conflict with the use case > below and it allows more. > Regards, > Filipe > On 17/02/21 18:38, Dave Cramer wrote: > > > On Wed, 17 Feb 2021 at 13:33, Douglas Surber > wrote: > I wrote the original proposal. The intent was to handle the case Lance > described. It was not intended to allow multiple executions of the > Statement. So while the language may not be as clear as it needs to be, the > case Filipe described should throw on the second execution of the > Statement. At least that was my intent. > > > Well there's enough hints in the wording to figure that out, but they are > just hints. > We (postgres) are going to implement it in such a way that the statement > will not be executed twice > > Dave > > Douglas > ________________________________ > From: jdbc-spec-discuss jdbc-spec-discuss-retn at openjdk.java.net>> on behalf of Lance Andersen < > lance.andersen at oracle.com> > Sent: Wednesday, February 17, 2021 9:52 AM > To: Dave Cramer > > Cc: Filipe Silva >; > jdbc-spec-discuss at openjdk.java.net jdbc-spec-discuss at openjdk.java.net> > > Subject: Re: closeOnCompletion > > I will have to go dig back through my email archive as this was first > discussed in 2009. > > > The overall intent was to deal with code similar to: > > ---------------------- > ResultSet rs = foo(); > while(rs.next() { > /*do something */ > } > rs.close(); > > public ResultSet foo() { > > Statement stmt = con.createStatement(); > stmt.closeOnCompletion(); > ResultSet rs = stmt.executeQuery(aQuery); > return rs > > } > ------------------ > > > We did spend a lot of time on this back in 2009 and took quite a bit of > time to reach agreement on the current wording. However, it does look > like there is the potential for some additional word smithing. > > Best > Lance > > > > On Feb 17, 2021, at 12:34 PM, Dave Cramer davecramer at gmail.com> davecramer at gmail.com>>> wrote: > > On Wed, 17 Feb 2021 at 12:13, Filipe Silva filipe.silva at oracle.com>>> wrote: > > On 17/02/21 10:53, Dave Cramer wrote: > Interesting situation. > > If we have an open statement with open resultsets and call > closeOnCompletion and then execute the statement a second time the > statement will throw an already closed exception since the spec says that > executing a statement a second time closes any open resultsets. Closing > said resultsets ends up closing the statement. > > I'm just confirming that this is the intended behaviour. Seems about > right > since if you set closeOnCompletion you would not expect to re-use the > statement. > > Dave Cramer > No, I don't think it is supposed to work like this. "Completion" means > that the user is done with the ResultSet(s) and explicitely calls > close() on it/them. > > Successive executions do close previously opened ResultSets but closing > those ResultSets implicitely (by re-executing) do not close the > Statement. The documentation makes it clear when it says "a call to > |closeOnCompletion| does effect both the *subsequent execution of > statements*, (...)". There would be no "subsequent execution of > statements" if the behavior was the one you described. > > > Well interestingly I'm told that the Oracle driver does close the statement > on subsequent execution. > > Either way I'm not sure I agree with the inference. Now we have to debate > the word execution. Is calling the method an execution or is completing the > call an execution ? > > Dave Cramer > > -- > [Oracle] > Filipe Silva, Senior Software Developer > Mobile: +351.91.009.2110 > MySQL Middleware and Clients > Oracle Portugal, Lagoas Park, Edif?cio N.? 8, 2740-244 Porto Salvo > > -- > [Oracle] > Filipe Silva, Senior Software Developer > Mobile: +351.91.009.2110 > MySQL Middleware and Clients > Oracle Portugal, Lagoas Park, Edif?cio N.? 8, 2740-244 Porto Salvo > > From alex at nexttypes.com Thu Feb 25 21:41:18 2021 From: alex at nexttypes.com (Alejandro =?ISO-8859-1?Q?S=E1nchez?=) Date: Thu, 25 Feb 2021 22:41:18 +0100 Subject: Systems Integration and Raising of the Abstraction Level Message-ID: We have highly evolved systems such as SQL, HTTP, HTML, file formats or high level programming languages such as Java or PHP that allow us to program many things with little code. Even so a lot of effort is invested in the integration of these systems. To try to reduce this problem libraries and frameworks that help in some ways are created but the integration is not complete. It is well known that most of the time when you try to create something to integrate several incompatible systems what you get in the end is to have another incompatible system :). Still I think the integration between the systems mentioned above is something very important that can mean a great step in the evolution of computing and worth a try. To explore how this integration can be I have created a framework that I have called NextTypes and that its main objective is the integration of data types. For me it is something very illogical that something as basic as a 16 bits integer receives a different name in each of the systems ("smallint", "short", "number") and can also be signed or unsigned. In any moment, due to a mistake from the programmer, the number of the programming language does not fit in the database column. Besides these names are little indicative of its characteristics, it would be clearer for example to use "int16". Whatever names are chosen the most important thing is to use in all systems the same names for types of the same characteristics. Also there is no standard system for defining composite data types of primitive types and other composite types. From an HTML form to a SQL table or from one application to another are required multiple transformations of the data. Lack of integration also lowers the level of abstraction, making it necessary to do lots of low level stuff for systems to fit. NextTypes at this moment is nothing more than another incompatible system with the others. It simply integrates them quite a bit and raises the level of abstraction. But what I would like is that the things that compose NextTypes were included in the systems it integrates. Finally I would like to list some examples of improvements in database managers, SQL, HTTP, HTML, browsers and programming languages that would help the integration and elevation of the level of abstraction. Some of these enhancements are already included in NextTypes and other frameworks. SQL --- - Custom metadata in tables and columns. - Date of creation and modification of the rows. - Date of creation and modification of the definition of the tables. - Use of table and column names in prepared statements. Example: select # from # where # = ?; - Use of arrays in prepared statements. Example: select # from article where id in (?); # = author,title ? = 10,24,45 - Standardization of ranges of valid values and resolution for date, time and datetime types in database managers an HTML time element. PostgreSQL ---------- - Facilitate access to the definition of full text search indexes with a function to parse "pg_index.indexprs" column. Other database managers ----------------------- - Allow transactional DDL, deferrable constraints and composite types. JDBC ---- - High level methods that allow queries with the execution of a single method. Example: Tuple [] tuples = query("select author,title from article where id in (?), ids); - Integration with java.time data types. HTTP - Servers -------------- - Processing of arrays of elements composed of several parameters. fields:0:type = string fields:0:name = title fields:0:parameters = 250 fields:0:not_null = true fields:1:type = string fields:1:name = author fields:1:parameters = 250 fields:1:not_null = true Another possibility is to generate in the browser arrays of JSON objects from the forms. "fields": [ { "type": "string", "name": "title", "parameters": 250, "not_null": true }, { "type": "string", "name": "author", "parameters": 250, "not_null": true } ] XML/HTML - BROWSER ------------------ - Input elements for different types of numbers with min and max values: 16 bits integer, 32 bits integer, 32 bits float and 64 bits float. - Input elements for images, audios and videos with preview. - Timezone input element. - Boolean input element with "true" and "false" values. - Null value in file inputs. - Clear button in file inputs like in date and time inputs. - Show size in file inputs. - Extension of the DOM API with high level and chainable methods. Example: paragraph.appendElement("a").setAttribute("href", "/article"); - Change of the "action" parameter of the forms to "target" to indicate the URL where to execute the action. The "action" parameter is moved to the different buttons on the form and allows executing a different action with each of the the buttons. Example:
- "select" elements that change a parameter of the current URL. Example: Example query URL: "/article?lang=en&view=json&names&search=Ne" - Same appearance and operation of inputs with dynamic datalist in all browsers. - Option tags with icons. Example: - Tabs, Tree, etc widgets - Mechanism to close HTTPS sessions initiated with client certificate authentication. JAVA ---- - Subclasses of String or some system of variants of String that allows assigning a regular expression or class that limits its valid values to avoid code injection or values that will crash the system. Example: String:Type = "[a-z0-9 _] +"; Or String:Type = TypeChecks; String:Type type = "article_language"; -> correct String:Type type = "Article-Language"; -> error We can talk about the characteristics of each system in its mailing list or group. For the general topic of system integration I have created a discussion in the github project. https://github.com/alejsanc/nexttypes/discussions/6 This email has been sent to the following mailing lists and groups: pgsql-hackers at lists.postgresql.org pgsql-jdbc at lists.postgresql.org mozilla.dev.platform at googlegroups.com public-html at w3.org jdbc-spec-discuss at openjdk.java.net jdk-dev at openjdk.java.net maria-developers at lists.launchpad.net chromium-dev at chromium.org https://mysqlcommunity.slack.com/archives/C8R1336M7 Best regards. Alejandro S?nchez.