I want type(pyDataset) so that I can confirm datatypes when processing data. Without having a pydataset on hand, I can't figure out how to fetch that type. This seems like it should be pretty straightforward, I just don't know the command.
Grab the .underlyingDataset, from which you can get the columnTypes (and columnNames, too).
Consider bookmarking the SDK JavaDocs...
2 Likes
This is a useful insight -- I didn't know about that accessor. But that still requires having a dataset on hand. I am trying to error handle in a messageHandler so that the wrong data type doesn't get processed and I wont necessarily have a pydataset available to access. Is there a way to access the type directly like isinstance(myObject, pyDataSet)
No. That will only see the type of the PyDataset wrapper. You can use type() on the underlying dataset. What do you mean by "wrong type" ? All dataset implementations have almost the same methods.
What do you mean by "wrong type" ? All dataset implementations have almost the same methods.
Well I'd handle a list of strings differently than a dataset, for instance.
That will only see the type of the PyDataset wrapper.
That's fine with me, I don't need the underlying information for this particular use case. I want to do things like system.dataset.toCSV but be sure that my dataset object is a dataset.
Well, you cannot wrap a list of strings with PyDataset. But note, for several years now, the PyDataset wrapper also implements the Dataset interface. Just check for Dataset with isinstance().
The zen of Python says "try it and see if it blows up". You should get a specific type error if you pass something that cannot be coerced.
In general worrying about explicit types means you're (potentially) locking yourself into a more explicit contract than you might want; there absolutely are scenarios where you need to be explicit about input or output types but I'm not sure the example given here is one of them.
This sort of points at the crux of my problem
isinstance(4, Dataset)
Traceback (most recent call last):
File "<input>", line 1, in <module>
NameError: name 'Dataset' is not defined
Yeah, I can play whack-a-mole with try/except, but I would rather check imperatively and have my exceptions be reserved for true exceptions. Plus, I don't know how to interrogate certain parts of the jython interface and this would add to my knowledge there.
add
from com.inductiveautomation.ignition.common import Dataset
2 Likes
That's it!
Thanks
Sigh. The javadocs I linked show you the complete package and class names you need. Importing java packages and/or classes is just like importing python, except that you cannot use wildcards.
Ah see but I was looking for python answers and I have a natural fear and hatred of all java systems
1 Like
Hate to break this to you, but Ignition is built with java. Just sayin`.
Arguably, the moment you start interfacing with the Java side of Ignition, you know you're jumping off the deep end.
In my (admittedly limited) experience, the documentation for the Jython functions is much better than the documentation for any of the Java libraries used
Oh don't worry it has long since been broken over my head like a barstool
That is deliberate. The Ignition manual documents what is supported. The SDK is for extending the platform, but it is all subject to change. "Implementation details" that happen to be really useful beyond the SDK, particularly with jython's tight integration with java. 
1 Like
Even stuff like the Extension Function configureChart requires getting into the JFreeChart objects, which are annoying.
It's not just digging into the Ignition SDK where weird java comes up
That doesn't really contradict Phil's point.
IA's official support, in your example, ends at "does the configureChart function exist, fire when it's supposed to, and give you the parameters it's supposed to". Any scripting you do against JFreeChart's own APIs is your own prerogative.
Also, seriously, Java is a perfectly fine language. It's crusty and for a period of time had an awful culture of verbosity re: EnterpriseServiceFactorySingletonManagerPatterns, but it's a workable multiparadigm language backed by a very good VM. And, like it or not, Ignition's always going to run on Java, so if you choose to do the more advanced things the platform lets you, you're going to want to learn at least some of our platform's conventions.
2 Likes
Oh, don't get me wrong, I love Java. It's what I learned to code on, and honestly, what I'm most comfortable in.
It just happens that "Java" in Ignition tends to mean that you are stepping into areas which aren't supported. I like the option to dive into these things -- although I wish that more of them were officially supported.
It's still way better to have "You can do this if you spend an hour reading through weird APIs" than "It's literally impossible to do what you are asking".
1 Like