ontext.getPersistenceInterface().createNew fails to make new record - cannot find any log data

Ignition
1

Hi I have the following code:

import simpleorm.dataset.SQuery as SQuery
import com.inductiveautomation.ignition.gateway.localdb.persistence
class TestRecords(com.inductiveautomation.ignition.gateway.localdb.persistence.PersistentRecord):
	pass
			
TestRecords.META = com.inductiveautomation.ignition.gateway.localdb.persistence.RecordMeta(TestRecords,'TestRecords')
TestRecords.Id = com.inductiveautomation.ignition.gateway.localdb.persistence.IdentityField (TestRecords.META)
		
from com.inductiveautomation.ignition.gateway import IgnitionGateway
context = IgnitionGateway.get()
context.getSchemaUpdater().updatePersistentRecords(TestRecords.META)
		
query = SQuery(TestRecords.META)
results = context.getPersistenceInterface().query(query)
		
interface = context.getPersistenceInterface()
new_test_record = context.getPersistenceInterface().createNew(TestRecords.META)
context.getPersistenceInterface().save(new_test_record)

But when I run it I get the following error on the line

new_test_record = context.getPersistenceInterface().createNew(TestRecords.META)

SException$Error: simpleorm.utils.SException$Error: Unable to get new record instance from [SRecM 75]

Does anyone know why this might be the case, I cannot find anything useful in the logs even after turning all the SimpleORM loggers to trace

The schema goes in and it creates the table just fine but it will not create a new record instance (before I even get to the point of saving it to the db)

Any help would be greatly appreciated

2

Hmm, this should also come with a stack trace from the underlying exception. You might be able to catch the exception explicitly and log the underlying cause.

The record instance is instantiated via reflection, and I wouldn't be surprised if for some reason this doesn't work with the adhoc class you just defined in Jython.

None of this API is meant for consumption by scripting :person_shrugging:

2 Likes
3

Thanks Kevin, looking at the JavaException.getCause() yields:

Caused by: RuntimeError: maximum recursion depth exceeded (Java StackOverflowError)

is this unavoidable in trying to tackle this in Jython?

What is the Ignition recommended way to store configuration variables for scripting functions which can be configured during runtime (eg via a configuration view/page)?

I would prefer not to use a tag provider as those vary deployment to deployment and in the cases of functions which do not use a database then I cannot store the variables there. I was considering writing to a local file but then I cannot leverage the ignition gateway redundancy and backup functions. The ORM seemed like the most reliable place to store configuration data but looks like it might not be feasible.

Thanks again.

4

I'm pretty sure Jython cannot supply actual static fields for the java proxies of jython subclasses. So this will never work.

No formal recommendation from IA, but I would recommend:

  • Use a database, and load the constants from it into a top-level cache object (typically a dictionary) in a project script module, or

  • Use a JSON file outside the /data/ folder of the Ignition install, and load it into a top-level cache object in a project script module.

In both cases, do the work in a function that can be re-executed after updates are made to DB or JSON.

5

Thanks for the recommendations Phil.
Why do you suggest a JSON file outside the /data/ folder? I think in the past I usually throw internal SQLite application/Config DBs etc in the /data/ folder as that seems to be the convention (I usually only store external data outside the data folder).

6

Because the data folder is included in gateway backups. Gateway-specific settings need to be outside.

7

Phil I feel like I'm missing something here but wouldn't you want config files for something running on a gateway to be backed up in the gateway backups?

Perhaps the use-case we're discussing is slightly different? So I guess I'll ask:

What issue are you preventing / what benefit are you getting by storing configuration files outside of the data folder?

I normally put everything in the data folder so that if there is an issue a backup can be restored and all of the functions still work which rely on those configuration files (rather than potentially losing them and having to reconfigure a bunch of things before the gateway is back up and running completely). Same thing goes for java modules.

Interested to know if I've been doing something I shouldn't be

8

You said the information to be stored includes per-user runtime selections. Those should not be in a gateway backup, because a restore would blow away those choices.

Things that are truly constants for the application, wherever deployed, can certainly be in files that ride along with a gateway backup. Anything else belongs elsewhere. Usually a DB, but outside /data/ if a DB is not available.

If you have items of both kind, use both methods.