As an aside, I’m aware that system.db.toDataSet() is not a function in the User Manual and it is actually system.dataset.toDataSet() but it appears to resolve anyways…not sure about that one.
Essentially just wanted to see if this behavior is intended:
Functions that used to return PyDataSets now return BasicDataSets
You cannot convert a BasicDataset into a BasicDataSet
This does look like an unintended side-effect of the consolidation of the PyDataset type. In v8.3, all Dataset implementations are naturally alsoPyDataset instances. No conversions in either direction are needed in v8.3.
Ignition 8.3 introduces a newPyDataset wrapper, (as opposed to the old DatasetUtilities.PyDataSet), and does some trickery to ensure all scripting that returns a Dataset automatically wraps it with this wrapper...
So in the end conversion should be unnecessary, the old DatasetUtilities.PyDataSet is deprecated, the toPyDataSet function is deprecated, and conversion should generally be automatic... but it's not accurate to say all Dataset are PyDataset - that'll get you in trouble if you end up somewhere that types matter.
Ok. Is the "trickery" the use of Py.getAdapter() to install a global, automatic wrapper? If so, I'm happy, as that means anyDataset will get the wrapper, even if delivered by non-IA code.
If that isn't the trickery, I'll open a ticket to get it fixed.
I gotcha, it’s more about hunting down all the instances where we convert what used to be a PyDataSet to a BasicDataSet. Can I expect that any other system functions that used to return PyDataSets have this behavior as well?
I gotcha, it looks like since system.util.getSessionInfo() now returns a BasicDataSet using the toDataSet conversion has broken a bunch of scripts we use for gateway maintenance.
If you had been using system.dataset.toDataSet this whole time, you would have never noticed. As in, your first test of "wrapping" a DS in a DS will work if you use system.dataset.toDataSet.
system.db.toDataSet has been deprecated and hidden since 2011, and is coded (on the Java "backend" side of things) in such a way that it requires you pass in a 'true' PyDataSet. DatasetUtilities, which is ultimately what system.dataset functions call into, would happily accept either type and (not) do the wrapping.
This is deliberately "supported", but is not actually doing anything; we're detecting that you're trying to 'wrap' and just handing back the original dataset.
The correct thing to do in an 8.3+ script is to just ignore the concept of pydatasets completely. Forget they ever existed, remove all operations that wrapped/unwrapped them, and have a happier life.
Understanding that that isn't the most practical on existing large codebases, I'd say that the easiest advice would be to machine edit/find & replace all instances of system.db.toDataSet and replace them with system.dataset.toDataSet. I'll eventually get this issue fixed first party now that we're aware of it, but prioritization/timing wise the absolute earliest public release you would potentially see this in would be mid-February. I doubt you can wait that long.
For a little bit of further detail on the shenanigans here: type(someWrappedDataset) will faithfully report the underlying dataset type instance, even through the automatic wrapping.
Also, the new wrapper class is com.inductiveautomation.ignition.common.script.builtin.PyDataset, distinct from com.inductiveautomation.ignition.common.script.builtin.DatasetUtilities.PyDataSet, and there's no subtype relationship between them. Note that different in capitalization.
So far this is the only significant edge case I'm aware of that slipped through all manual and automated testing of 8.1 vs 8.3, and it's with a 14-year deprecated scripting function, so I'll take it.
