Establish a “grnsettings” table that potentially stores default values—start with default expression data set

[dondi]

There is a need to provide a default expression data set to use when creating a brand new network from the database. The right long-term design for this is a grnsettings table which will start with just this column but can expand further:

• Design and definition of the table
• Implementation of the table in the database
• Implementation of a DAL function that accesses this table
• Implementation of an API function that calls the DAL function and passes it to the requester (the web app)
• Implementation of web app code that makes use of this value

[dondi]

A network data source setting may be good to add as well—check with @Onariaginosa

[ahmad00m]

I finished the dal function and the dal-calling method, however I have a problem with env variable. The libraries are successfully installed but when I call the execute method I get an error. I tried troubleshooting it but it didn't work, I will try to troubleshoot a little bit more then the web app code would be the only thing left.

[dondi]

@ahmad00m was able to fix the error by using the SQLAlchemy text import. However this is inconsistent with prior code that we have seen/written. First check is to see if SQLAlchemy versions have changed in this way; also check documentation for session.execute to see if this is explicitly asked for

Bottom line is we want to determine why text had to be used in @ahmad00m’s case

And either way, we’ll want to do this in JavaScript anyway, but would be nice to still get an explanation for this

[ahmad00m]

I believe grnsettings-dal function and expression function are ready to replaced the hardcoded dataset name. However, I didn't get a chance to test for that. I will finish the last touches and then make a pull request.

[ahmad00m]

Also, the reason we had to use text for the raw SQL query is explained here. It mentions that the functions of connectionless executions are deprecated for sqlalchemy V.2.0.

[ahmad00m]

@ahmad00m will finish testing the code to retrieve the default expression-dataset name from the database.

[ahmad00m]

I finished debugging the code and tried to replace the hard-coded dataset names in the update-app.js but I was not successful because I got an issue with node again. I pulled from Ona's branch this morning to see if that fixed the problem but it didn't. I changed the pg version to 8.0.3 and I'm on node 14.21.2 and installed node again, but that doesn't seem to resolve the issue.

[ahmad00m]

I tried incorporating grnsettings database into the update-app.js but the app crashes when I load the controller file in app.js. I'm working on figuring out how to solve this, I believe I may be missing an import or there is a bug in my controller/dal files. This is the error I get when I try to compile my local copy.

[dondi]

We were able to resolve the MODULE_NOT_FOUND error by making sure that the filename matched the require parameter

[ahmad00m]

@ahmad00m has implemented all the functions required to retrieve the default dataset name from the database. However, the code is not yet fully functional due to the synchronization issue on the update-app.js. So, I will have to look into the synchronization method on javascript so that by the time that update-app.js code is ran the dataset name is retrieved from the database. @dondi has suggested two ways to resolve this problem. One is to change all the functions in to async using the await method. The other solution is to adapt my function to retrieve and save the dataset name into a variable in the .then(response) method and then use that variable to set the dataset name.

I will first try to adapt my code using the second suggestion and if was unable to resolve the problem we will have to change the settings in the update-app.js to accept async functions.

[dondi]

A few more details as determined during the power outage meeting of 2023:

• grnState can no longer be a static object; instead, we will need an async function that produces it. Doing so will allow us to await the results of database queries in order to populate grnState
• When grnsight.js runs, we need to restructure that sequence so that we await/then the final value of grnState and then use that value for the other functions
• There may be other parts in the code that assume grnState is static—as @ahmad00m encounters them, we will try to find a minimal-impact strategy to transition this

If we wish to use the relatively newer async/await syntax, we will need to update our linter/compiler to a version that recognizes it

(possible) Links:

• https://jestjs.io/docs/29.1/tutorial-async
• https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Asynchronous (beginning might be more basic than needed, just skip as appropriate)

[ahmad00m]

I was able to update the eslint from 3.19.0 to 8.38.0 to allow for async await functions. It was interesting to note that during my research I found it eslint supports async await functions at 3.11.0 and above; however for some reason it wasn't functional. Then, I exported grnState as a async function and also created an async method to retrieve the default database name which seems to be functional. However when I replace the hard code default name with this function the function name still doesn't get retrieved. Moreover, when I converted grnState into an async function I got the following error which I hope to resolve during the meeting.

Also, I want to note that the second website suggested above was very useful in understanding the async await function and promises.

[ahmad00m]

This issue is resolved with help from @dondi. I committed my code to my branch. I will have to make sure there are no conflicts the current code and perform more testing and will then create a pull request to merge changes to beta.

[dondi]

To manage the impending migration from @Onariaginosa’s work, both @ahmad00m and @ntran18 will seek to manually revise their local databases so that they can fully test their branches

As far as we can tell, the main change is a change of schema name, which can be done manually via the ALTER SCHEMA command: https://www.postgresql.org/docs/current/sql-alterschema.html

There may be other changes but we can consult #1025 to track those down

@ahmad00m will do these on his local database first since he has more experience but he will then also help @ntran18 afterward

[dondi]

Last lingering issue appears to be linting because the software versions we’re using are not yet aware of async—this appears to be some combination of version update + possibly configuration, and possibly of eslint or babel or both

Some possible reference links:

• https://github.com/eslint/eslint/issues/11976
• https://eslint.org/docs/latest/rules/no-empty-function#allow-asyncfunctions
• https://grantnorwood.com/eslint-parsing-error-unexpected-token-visual-studio-code/

[kdahlquist]

I'm not sure what the state of this issue is--assigning to @dondi

[dondi]

This is finally on beta; it can be tested, and local setups will need to be updated to include the new grnsettings table.

[kdahlquist]

Follow-ups to this issue are on #1062