-
Notifications
You must be signed in to change notification settings - Fork 38
feat: The ability to use an existing odbc connection #282
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it! Thanks!
@@ -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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
odbcConnection
parameter of thetransportOptions
it 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.