January: 15

Notes

2025

• Supabase

  01:00AM

  The next major update should be ready by tomorrow, we want to keep the turso integration but also slowly build out the migration to the postgres. While that is going on, I want to start the front end of the discordsh server. The question remains if we want to use NextJS or Astro, hmm, both are already included in the monorepo but I am thinking that astro with shadcn would be a better move than material design and nextjs.

  01:34AM

  We want to include the Constraints for the discord_servers table, even though we already have them in the python code. This is just a double check for the sake of data integrity! Starting with the invite column, this is what I am thinking we will include.

CONSTRAINT ck_valid_invite_code CHECK (invite ~ '^[A-Za-z0-9-]{2,100}$')

Next column that we want to limit is the name. Actually, while looking at the name field, I believe it would make more sense to just drop the TEXT field and use a varchar field instead! We should limit it to about 100 characters, to be safe, we will do 101 characters. The name field will then be 101.

name VARCHAR(101) NOT NULL,

CONSTRAINT ck_name_combined CHECK (
        name ~ '^[\p{L}\p{N} _-]{2,100}$'
    ),

Okay the name was replaced from TEXT field to the varchar field and we added a basic check against common attack vectors. Granted we will not be letting the server owner directly edit the table through the RPC or supabase’s api client. The plan is still to use the python server as a medium of handling the discord_server data.

Okay, that field is out of the way, the next field will be summary and we will follow the same logic. Dropping the TEXT and using a VARCHAR instead.

summary VARCHAR(200) NOT NULL,

CONSTRAINT ck_summary_combined CHECK (
    summary ~ '^[\p{L}\p{N} _\-,.!?]{2,200}$'
)

That will handle the summary issue for our use case! Okay quickly added description and website as well. Both need an additional sanitization before they get added into the table but we will handle that from the python side.

• FastAPI

  The next move would be to see if we can get the SQLModels to work with the Supabase API.

2024

• 4:40pm - outpost

  outpost

  These are just some small notes for the outpost. This issue ticket will keep track of it: 503 So under the Nx Outpost, I could add the automated report to that folder. In addition, I could also test case some PDF processing, converting it over to a MD/MDX using Ollama. During the folder creations for the outpost, I will throw in a .gitkeep to help keep track of the folders. Furthermore, I believe I should include a MD file that we could test case under the egui, I would want to pull that file and see if it can be rendered.

• 5:26pm - migration

  migration

  Going to tackle the 502 issue right now because it would be related to the 503. I will create a new folder under /data/ for scripts!

  Okay so for the outpost scripts, we will place them under /tools/scripts/public , which is a symbolic link to /apps/kbve.com/public/data/scripts. For organization, we will call this the /outpost/nx/ and the script name will be report.sh.

  Actually I am thinking of just using the ./kbve.sh shell file as the base for creating the report file. I believe I would need to also build out a base template for the markdown files. Thus, under the /data/ folder, I will go ahead and create a mdx folder, where I will store the templates for the time being.

  As I am currently test casing the report script, here is the command to run it, as of right now.

  
      ./kbve.sh -createmarkdown report ./apps/kbve.com/public/data/outpost/nx/report.mdx
  
  

  This command would create the report.mdx as a file in the outpost location.

Quote

“.” —

Tasks

• - Cleaning up read me.