I am looking for the format of the keyword strings. I have not been able to find this in the documentation.
Thank You,
Anthony Todd
There first parameter is a PyObject[] of values, the second is a String[] of corresponding keywords.
The keywords can be inferred from the documentation for the corresponding scripting function, e.g. https://docs.inductiveautomation.com/display/DOC79/system.db.runPrepQuery
There’s no further documentation because you’re attempting to use classes that aren’t part of the public API and aren’t meant for you to use.
Hi Kevin,
This is where we left off last time. If not the ClientDBUtilities as were suggested prior, what should I use to run queries from a client script? I am needing to run queries from a client script of a module.
Thank You,
Anthony Todd
Like I said (or backtracked to) in the other post: use RPC to implement the logic of your functions that need to access the database in the gateway scope. Get the DatasourceManager from GatewayContext, get an SRConnection, and run queries on that connection.
This is what I was doing before, when I was told the gateway was not the proper place to be running these. Now you telling me there is no way to make DB calls from the client scripts?
Sorry if the water got muddied in the other thread.
Queries do not run in the client. Even the client implementation of our DB scripting functions, which are implemented by the ClientDBUtilities @pturmel kept trying to recommend, just uses a private RPC mechanism to send them to the gateway to run.
Sigh. )-:
Our OP was having trouble creating the necessary RPC architecture. ClientDBUtilities has one ready to go. Not only ready to go, but precisely appropriate for the jython he wants to re-implement. You are recommending he construct his own RPC implementation that does exactly the same thing.
And still recommend. Your comments suggest that this class might go away someday, but other than the class name, you can't really get rid of the methods. IA is going to have a class that behaves this way with those exact named methods with that standard jython calling convention, or you won't end up with system.db.runPrepQuery in your namespace. Even if you deprecate it.
The OP has working jython that he wants to turn into non-designer-editable Java. Calling exactly the same functions from java is the right recipe to not screw up this conversion task. I'm a bit stumped Kevin, at your insistence Anthony not use ClientDBUtilities. He's writing a module with the SDK -- IA is not responsible for API breakage. It seems to me his long-term support will be much simpler if he just has to fix up some imports when/if you mess with ClientDBUtilities.
He'd be even more future-proof if he converted his queries to named queries, in jython first for convenient testing, but the same argument applies to that script function as far as the RPC implementation is concerned. What am I missing?
I have no interest in supporting it, documenting it, or answering further questions. The API is non-obvious because it's not meant for consumption from Java. If he uses it his project will have to have legacy querying enabled, reducing security rather than increasing it. And he's not as advanced of a user as you are so all of this is non-obvious and requires my time (and others) to explain and support.
I can see definite advantages to developing my application in the client script. Most obvious is the ability to have many classes, without making it a kludge. However if support and documentation is not available for DB access, it is a non starter for me. This seems quite odd to me, that no DB access at the client has been implemented. It seems this would be one of the first things developed for the SDK. May I make a request that a Java-centric version of the ClientDBUtilities be officially added to the SDK in the near future. Since you already have a well tested Jython version, it should be a no-brainer.
And @pturmel, my initial problem I was having was getting the gateway context. That had been solved, and I had several dozen RPC methods implemented and tested, when all this move to the client stuff began. The discussion that got all of this started was about options to get around the limitation of having only one RPC class per project, which is a system limitation. Not that I was having trouble creating the necessary RPC architecture.
Thanks,
Anthony Todd
One thing to watch out for that was alluded to: do not send query strings over RPC. Send the parameters to the function call. Perform any logic, assemble, and execute the query in the gateway.
I have all the Logic and Queries in the Gateway Scripts
Thanks 