Hi Kevin,
OK… After looking at the differences in how the gateway based and client based modules are configured, It looks like the client based would probably be easier to develop and maintain for the long run. I have converted everything to be client based… I setup the multiply example and got it to compile and run. I am having a bit of a problem working with the ClientDBUtilities though. At least with the gateway based module the DB access was working. I have gotten to the point of just trying anything and everything, and I can’t even get it to the point that IntelliJ quits complaining. A user guide for the utilities would be nice. I have not found one example or explanation of it anywhere. Java Docs aren’t really documentation in my opinion. Would it be possible to give me a full working example of the runQueryPrep and passing in the args? I believe I will be off to the races at that point. Until then, I am busy stubbing out a couple of hundred methods.
Thanks,
Anthony Todd
I should have looked closer before suggesting you could use ClientDBUtilities. @pturmel mentioning AbstractDBUtilities put me on autopilot…
All of these utility classes, while they happen to be accessible on the classpath, are not really public API. They are the implementations for our own scripting functions, and that’s why a lot of the method signatures are so obscure looking (because they’re meant to be invoked from Jython using keyword-args).
I’m not super familiar with programming in the client scope, especially as a module author. Perhaps using RPC for calls that need database access is the best practice. Accessing DB from the gateway scope is straightforward.
Leveraging ClientDBUtilities is the best way to maintain security. Otherwise you might be in for surprises, or you’ll have to enforce security yourself. ClientDBUtilities also provides the same call signatures that your existing scripts are using, providing a proven conversion path. I wouldn’t dismiss it out of hand.
Hi Phil,
I have not dismissed it, in fact this is exactly what I have been trying to do, I just can’t seem to make it work. Despite the fact that it has the same calls, they are not implemented in a similar manner. I really do need a full working example of how to implement at least one of these calls, including passing the args. The two calls I know I will need for sure are runUpdaateQuery and runQueryPrep. This appears to be the only thing I am missing at this point.
Thank You,
Anthony Todd
The jython call model is really generic. Two arguments are passed: an array of PyObject arguments, and an array of String keywords. The keywords supplied align with the trailing PyObjects. Functions that don’t accept keywords will throw an exception if the latter array isn’t empty. The rest of the arguments are positional.
For example, see these signatures from AbstractDBUtilities:
public Integer runUpdateQuery(final PyObject[] pyArgs, final String[] keywords);
public Integer runPrepUpdate(final PyObject[] pyArgs, final String[] keywords);
In your script module, you will need to instantiate it with the client context, and create an instance of ClientDBUtilities in your constructor. Then the methods exposed to your users can call the utilities like so:
public Integer indirectPrepUpdate(PyObject query, PyObject args) {
return myClientDBU.runPrepUpdate(new PyObject[] { query, args }, new String[0]);
}
If you want your methods to handle keyword arguments, too, you’ll have to pluck out the ones that are meaningful to you, and repackage just what the client DB utilities want.
My understanding is that he simply needs to be able to make database calls to implement some of his scripting functions, not re-expose runUpdateQuery and runPrepQuery. The only "security" he's inheriting by using ClientDBUtilities is the whether legacy queries vs. named queries are allowed, and this is arguably a bad thing in his case, because if the project is set up so only named queries are allowed all his database calls through ClientDBUtilities will start failing...
@anthony.todd maybe you can clarify here...
Sorry for the delay guys,
I live in Belgium, so I just got back from visiting family. Yes that is correct I just need to run the same queries that are currently being run from Python. Nothing fancy, I am simply encapsulating the existing python functions as methods in a module. These functions all have queries contained in them. I want to keep it as straight forward and easy to maintain as possible. It will have to be maintained for many years to come.
Thanks,
Anthony Todd
Going to bed now, I’ll check in the morning 
Well, that's a good argument for switching to named queries. I'd still go through ClientDBUtilities to execute the named queries (with the corresponding methods).
My example was intended to be a bare-bones syntax "how-to", not fully functioning code for his case. Anthony's wish for a "full working example" is unlikely to come true. Sorry, Anthony.
Hi Guys,
I really see no advantage in switching to named queries. As stated earlier, I just want to encapsulate the existing scripting in a module. I do not understand why this has to be so hard.
@Kevin.Herron can you send me a mail? I would like to share some things with you that I do not want posted on an open forum. My email anthony.todd@ats-global.com
Thanks,
Anthony Todd