feat: The ability to use an existing odbc connection #282
Conversation
ehenson
changed the title
There was a problem hiding this comment.
This looks like it will work. I think the next step is to add some functional tests ensuring it works. Can you show how you create the existing odbc connection that gets passed to the transport?
I see that this your first time contributing, to accept your patches we ask that you please sign-off your commits. This can be done with the commands suggsted by the DCO bot.
Thanks for your contribution!
|
In the initialization I am creating the pool:
I obtain a connection:
finally, I pass it to the itoolkit Connection: const connection = new Connection({
transport: 'odbc',
transportOptions: {
odbcConnection: this._odbcConnection,
},
}); |
|
My apologies for the lack of signOffs. I have realized that I have forgotten about the contributors document and I have now configured my tools for signOff and gpg. |
|
👋 Hi! This pull request has been marked stale due to inactivity. If no further activity occurs, it will automatically be closed. |
There was a problem hiding this comment.
Sorry for the late reply, Looks the commits 5cd87d9 34998ba 6de2075 12b6263 were accidently signed off on. These commits should not be apart of this PR. You can clean things up by running.
$ git rebase -i HEAD~8
Then prefixing the commits with d as shown below:
Lastly force push up the changes to your branch
Signed-off-by: Eric Henson <ehenson238@gmail.com>
Signed-off-by: Eric Henson <ehenson238@gmail.com>
Signed-off-by: Eric Henson <ehenson238@gmail.com>
Signed-off-by: Eric Henson <ehenson238@gmail.com>
| function processResults(results) { | ||
| if (!results) { | ||
| done('Empty result set was returned', null); | ||
| return; | ||
| } | ||
|
|
||
| let xmlOutput = ''; | ||
|
|
||
| results.forEach((chunk) => { | ||
| xmlOutput += chunk.OUT151; | ||
| }); | ||
| done(null, xmlOutput); | ||
| } | ||
|
|
||
| function query(connection) { | ||
| connection.query(sql, [ipc, ctl, xmlInput], (queryError, results) => { | ||
| if (queryError) { | ||
| done(queryError, null); | ||
| return; | ||
| } | ||
| connection.close((closeError) => { | ||
| if (closeError) { | ||
| done(closeError, null); | ||
| return; | ||
| } | ||
|
|
||
| if (!results) { | ||
| done('Empty result set was returned', null); | ||
| return; | ||
| } | ||
| if (!odbcConnection) { | ||
| connection.close((closeError) => { | ||
| if (closeError) { | ||
| done(closeError, null); | ||
| return; | ||
| } | ||
|
|
||
| let xmlOutput = ''; | ||
|
|
||
| results.forEach((chunk) => { | ||
| xmlOutput += chunk.OUT151; | ||
| processResults(results); | ||
| }); | ||
| done(null, xmlOutput); | ||
| }); | ||
| } else { | ||
| processResults(results); | ||
| } | ||
| }); | ||
| }); | ||
| } |
There was a problem hiding this comment.
I think this would be great to get this merged in. I would like to request some changes before merging this one in though.
Instead of nesting the processResults and query functions maybe this should be split into one method because whether or not an existing connection is passed we would need to query xml service and process the results. The only difference would be if we should close the connection or not. If an existing connection was not passed close it otherwise don't call close.
Checkout this branch with how I think this could be done
Let me know If you have time to add the requested changes so we can fix this up otherwise I can pull these changes from this branch into a new PR and work on getting it merged.
There was a problem hiding this comment.
@abmusse
As much as I would like to assist, I cannot get to this any time soon. Sorry!
You are correct about "if we should close the connection or not."
Will the consuming application need to pass the shouldCloseConnection parameter instead of the code checking for a null/undefined connection object?
There was a problem hiding this comment.
We could make this a configurable transport option. That way the user could allow closing the connection object if desired. Would this be desirable for your application?
There was a problem hiding this comment.
I'm flexible either way as long as a programmer is fully aware that it will close the connection on their behalf unless the parameter is set appropriately. In my case, I use the same connection to query results of a program call in the QTEMP library, and if it's closed I'll lose the reference to the job.
There was a problem hiding this comment.
As written now, the consuming application would not need to pass shouldCloseConnection / is unable to at all. If a odbcConnection option is set/passed by the user shouldCloseConnection is set to false therefore not closing the passed connection. If a connection was not passed then we create one implicitly and run the query, process results, close out that connection.
| @@ -48,6 +49,7 @@ const availableTransports = { | |||
| * @property {string} [ipc=*NA] - The key name/security route to XMLSERVICE job. Default is ``*NA``. | |||
| * @property {string} [ctl=*here] - The control options for XMLSERVICE jobs. Default is ``*here``. | |||
| * @property {string} [xslib=QXMLSERV] - The XMLSERVICE library. Default is ``QXMLSERV``. | |||
| * @property {object} odbcConnection - An optional odbc connection instead of a creating a new one. | |||
There was a problem hiding this comment.
Line 52 documents the idb transport options therefore we should not add odbcConnection property here.
| * @property {object} odbcConnection - An optional odbc connection instead of a creating a new one. |
By setting the
odbcConnectionparameter of thetransportOptionsit will use the existing connection instead of creating and managing its own connection. This is useful to be able to run SQL queries in the same job. An example would be if a program created files in the QTEMP library and you need to retrieve the records.