sync JavaScript enums with PostgreSQL

[lindavin]

In our PostgreSQL database, we use enums for meter types. We also supply logical names for these types as an enum in the Meter class. These two enums need to be kept in sync, i.e. if we make changes to either one these enums in the future, we need to remember to change the other.

[RuxueJ]

Hello! Can I create a folder named "shared" which contains meterTypes.js and meterTypes.ts, which can export the type nums. Then I import one in src/client/app/types/redux/meters.ts , and import another in src/server/models/Meter.js? Since the two meterTypes file are in one folder, poeple will probably remember to keep them in sync.

[huss]

@RuxueJ Thanks for this idea. It is probably an improvement but I would like to see if there is a way to automatically keep the JS and TS in sync. If not, we could do what you suggest.

Also, this does not seme to address the direct issue of making the Postgres enums match the TS/JS ones. Any thoughts on that?

[DPJProgramming]

My team and I would Like to work on this issue.

[huss]

@DPJProgramming Thanks for wanting to work on this. I'm not sure how to make this work and I hope you can come up with ideas. I'm also happy to help as needed.

[EBoyd3443]

Hello! We've (@DPJProgramming, @dalejk88, @EBoyd3443, @Gballreich) set up an initial test case for checking JS objects to SQL enums:
https://github.com/EBoyd3443/OED/blob/development/src/server/test/db/enumTests.js
Any comments about the test case before we generalize for each other enum.

[huss]

Thanks to @DPJProgramming, @dalejk88, @EBoyd3443, @Gballreich for working on this. I have not run the code to check it but it seems good. Here are a few thoughts:

• The rest of the OED code base does:

const database = require('../../models/database');
const sqlFile = database.sqlFile;

so it might be best to do that.

• It is okay to add this to the sql/ directory. However, since it is only used in testing and is simple, I wonder about putting the SQL into the test file. Take a look at src/server/test/db/unitReadingsTests.js (line 53 is an example) where this is done in a test.
• The indenting around line 20/21 seems off as the loop over Meter.type is not part of the database loop.
• OED normally checks the length before the values. The reason is that the values will clearly fail and it is valuable to know the number involved. I'm not sure that strictly applies here as the other message would be okay but maybe do that for consistence unless there is a reason not to.
• Finally, comments in code is always helpful.
  I think it looks fine so it is okay to move forward on more tests if you are comfortable with these comments. I'm also happy to look again at any changes if that help you.

[EBoyd3443]

Hi Huss,
While we've finished our five tests for the DB enums which have JS object equivalents, and on the last one (unitType):

OED/src/server/sql/unit/create_unit_types_enum.sql

Line 8 in 82a74d6

CREATE TYPE unit_type AS ENUM('unit', 'meter', 'suffix');

(line 8)

OED/src/server/models/Unit.js

Line 232 in 82a74d6

Unit.unitType = Object.freeze({

(line 232)
These two do not equate. We've written the test for them, but wanted to double check that they should equate and if we should make any changes outside our tests when submitting the pull request.

[huss]

Well, this is an example of how testing can help find issues. Good catch and thanks for asking. I searched the code and Unit.AREA does not seem to be used. It has been a while but I think that is a remnant of the idea that area would be calculated on the server and use the unit concept. Instead, OED does the calculation on the client. So, Unit.AREA should be removed from the Object. Let me know if this causes any issues.

[Gballreich]

Currently we have an open pull request to create tests for keeping DB Enums in sync with the JS objects link here

What we tried to address the TS Enum tests:

• Creating a TS test file with it's own config.

• Pulling from the bundle.js TS output file.

After speaking with @huss 12.04.24 our team has come to the conclusion of:

• There is a possible solution by creating an individual route for testing the TS Enums. (not approved by @huss)
• There could be an underlying issue with the internal webpack.
• The best long term solution for this issue would be to convert the codebase to TS.
• @huss recommendation is to close this issue.

[huss]

As stated, I concur to close this issue. If anyone has ideas on how to check the TS enums then that would be welcome. When OED fully converts to TS then the tests for the JS objects that are logically enums should be converted to check the TS enums. The current client only enums could be compared to the DB ones. It is also assumed that a single enum will exist for the client and server.