@bslau/hmm_prisma_schema 1.1.22 → 1.2.0

package/README.md

@@ -1,31 +1,44 @@
-# Introduction 
-TODO: Give a short introduction of your project. Let this section explain the objectives or the motivation behind this project. 
+# Editing Prisma Schema
 
-# Getting Started
-TODO: Guide users through getting your code up and running on their own system. In this section you can talk about:
-1.	Installation process
-2.	Software dependencies
-3.	Latest releases
-4.	API references
+The general workflow will follow these steps:
 
-# Build and Test
-TODO: Describe and show how to build your code and run the tests. 
+- Create and checkout a new working branch.
+- Edit `schema.prisma` as needed.
+- Run automated formatting: `npx prisma format`
+- Prepare database changes (as needed):
+  - create (preview) migration: `npm prisma:create` or;
+  - create and apply migration: `npm prisma:apply`
+- Update *minor* version number in `package.json`
+  `"version": "[MAJOR].[MINOR].[PATCH]"`
+- Create and test new seeding function(s) if required - being cautious to avoid creating **duplicate** records on repeated runs.
+- Raise PR for merging back into main branch.
 
-# Edit prisma schema
-TODO: Explain how other users and developers can edit prisma schema. 
->create a branch
+The changes should be ready for review, merging, and publishing now.
 
->edit schema.prisma
+# Deploying Prisma Schema
 
->npx prisma format
+Completing the PR (merging into main) will automatically trigger the build and release pipelines that will publish the new version of the package to the remote npm repository.
 
->npx prisma migrate dev --name new schema
+The latest version can then be installed in the application implementing the schema:
 
->update version in package.json
+`npm install @bslau/hmm_prisma_schema`
 
->raise PR for merging to main branch
+*NOTE* that doing this on the BlueScope network will typically **fail**. Installing this package involves generating a fresh Prisma client file - this is the part that seems to stall/fail because it's ignorant of the system proxy settings. The workaround is to use a hotspot internet connection without any proxy settings instead.
 
-If you want to learn more about creating good readme files then refer the following [guidelines](https://docs.microsoft.com/en-us/azure/devops/repos/git/create-a-readme?view=azure-devops). You can also seek inspiration from the below readme files:
-- [ASP.NET Core](https://github.com/aspnet/Home)
-- [Visual Studio Code](https://github.com/Microsoft/vscode)
-- [Chakra Core](https://github.com/Microsoft/ChakraCore)
+# Manual Deployment for Test Environment
+
+Current implementations of this package **don't** automate migration and seeding steps after release to the Test environment. This will result in schema mismatch between the Prisma package and the Test database when updates are released. 
+
+The workaround is to manually execute these steps after release. This example describes the process for the *GraphQL Apollo* server, but would also work for the *Event Processing* service (albeit in a different directory):
+
+- RDP into the host server: `ITAVWEB91`
+
+- Open a bash terminal and navigate to the installed package:
+
+  `cd /c/inetpub/wwwroot/hmm/graphql_server/node_modules/@bslau/hmm_prisma_schema`
+
+- Apply any pending migrations: `npm run prisma:deploy`
+
+- Run the seed function to create data: `npm run prisma:seed`
+
+At this point, assuming no errors in deploying or seeding, the Test database schema should be synchronised with Prisma now.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bslau/hmm_prisma_schema",
-  "version": "1.1.22",
+  "version": "1.2.0",
   "main": "index.js",
   "author": "CIPA Development Team",
   "license": "ISC",
@@ -14,6 +14,7 @@
     "prisma:apply": "npx prisma migrate dev",
     "prisma:create": "npx prisma migrate dev --create-only",
     "prisma:deploy": "npx prisma migrate deploy",
+    "prisma:seed": "npx prisma db seed",
     "test": "echo \"Error: no test specified\" && exit 1"
   },
   "types": "./index.d.ts",

package/prisma/migrations/20250505063942_397526_torpedo_capacity_properties/migration.sql

@@ -0,0 +1,20 @@
+BEGIN TRY
+
+BEGIN TRAN;
+
+-- AlterTable
+ALTER TABLE [dbo].[Torpedo] ADD [capacityDynamic] FLOAT(53),
+[capacityNominal] FLOAT(53) NOT NULL CONSTRAINT [Torpedo_capacityNominal_df] DEFAULT 200;
+
+COMMIT TRAN;
+
+END TRY
+BEGIN CATCH
+
+IF @@TRANCOUNT > 0
+BEGIN
+    ROLLBACK TRAN;
+END;
+THROW
+
+END CATCH

package/prisma/migrations/20250505070105_397526_rename_capacity_dynamic_to_capacity_average/migration.sql

@@ -0,0 +1,26 @@
+/*
+  Warnings:
+
+  - You are about to drop the column `capacityDynamic` on the `Torpedo` table. All the data in the column will be lost.
+
+*/
+BEGIN TRY
+
+BEGIN TRAN;
+
+-- AlterTable
+ALTER TABLE [dbo].[Torpedo] DROP COLUMN [capacityDynamic];
+ALTER TABLE [dbo].[Torpedo] ADD [capacityAverage] FLOAT(53);
+
+COMMIT TRAN;
+
+END TRY
+BEGIN CATCH
+
+IF @@TRANCOUNT > 0
+BEGIN
+    ROLLBACK TRAN;
+END;
+THROW
+
+END CATCH

package/prisma/schema.prisma

@@ -325,8 +325,8 @@ model Torpedo {
   sixPitRestrictionEndTime DateTime?              @db.DateTimeOffset
   status                   Int                    @default(2)
   // sixPitStart DateTime?
-  // capacityDynamic Float?
-  // capacityNominal Float?
+  capacityAverage Float?
+  capacityNominal Float @default(200)
   // comments String?
   // emptyWeight Float?
   // gasStart DateTime?