@powerhousedao/academy 3.3.0-dev.12 → 3.3.0-dev.14

package/CHANGELOG.md

@@ -1,3 +1,11 @@
+## 3.3.0-dev.14 (2025-07-17)
+
+This was a version bump only for @powerhousedao/academy to align it with other projects, there were no code changes.
+
+## 3.3.0-dev.13 (2025-07-17)
+
+This was a version bump only for @powerhousedao/academy to align it with other projects, there were no code changes.
+
 ## 3.3.0-dev.12 (2025-07-17)
 
 ### 🩹 Fixes

package/docs/academy/02-MasteryTrack/04-WorkWithData/01-GraphQLAtPowerhouse.md

@@ -156,7 +156,7 @@ When dealing with lists of data, GraphQL employs a pattern that includes:
 
 ## GraphQL Subgraphs in Powerhouse
 
-Powerhouse structures its data into **subgraphs**, which are modular GraphQL services that connect to the Reactor (Powerhouse's core data infrastructure) or Operational Data Stores fueled by data from processors. Each subgraph has its own SDL, ensuring modularity and flexibility while working within the ecosystem.
+Powerhouse structures its data into **subgraphs**, which are modular GraphQL services that connect to the Reactor (Powerhouse's core data infrastructure) or Data Stores fueled by data from processors. Each subgraph has its own SDL, ensuring modularity and flexibility while working within the ecosystem.
 
 ### Fetching data from the Reactor
 

package/docs/academy/02-MasteryTrack/04-WorkWithData/03-UsingSubgraphs.md

@@ -14,7 +14,7 @@ A subgraph in Powerhouse is a **GraphQL-based modular data component** that exte
 ### Subgraphs can retrieve data from
 
 - **The Reactor** – The core Powerhouse data system or network node.   
-- **Operational Data Stores** – Structured data storage for operational processes, offering real-time updates, for querying structured data.  
+- **Relational Data Stores** – Structured data storage for operational processes, offering real-time updates, for querying structured data.  
 - **Analytics Stores** – Aggregated historical data, useful for insights, reporting and business intelligence.
 
 ### Subgraphs consist of

package/docs/academy/02-MasteryTrack/04-WorkWithData/07-OperationalDbProcessorTutorial/01-TodoList-example.md

@@ -4,7 +4,7 @@
 2. Define your database schema
 3. Customize the processor to your needs
 4. Test your processor
-5. Use the operational store in Frontend and Subgraph
+5. Use the relational database in Frontend and Subgraph
 
 
 ## Generate the Processor
@@ -25,9 +25,9 @@ The migration file has a up and a down function which gets called when either th
 Below you can find the example of a todo table.
 
 ```ts
-import { type IOperationalStore } from "document-drive/processors/types"
+import { type IBaseRelationalDb } from "document-drive/processors/types"
 
-export async function up(db: IOperationalStore): Promise<void> {
+export async function up(db: IBaseRelationalDb): Promise<void> {
   // Create table
   await db.schema
     .createTable("todo")
@@ -41,7 +41,7 @@ export async function up(db: IOperationalStore): Promise<void> {
   console.log(tables);
 }
 
-export async function down(db: IOperationalStore): Promise<void> {
+export async function down(db: IBaseRelationalDb): Promise<void> {
   // drop table
   await db.schema.dropTable("todo").execute();
 }
@@ -74,7 +74,7 @@ export const todoProcessorProcessorFactory =
     const namespace = TodoProcessorProcessor.getNamespace(driveId);
 
     // Create a filter for the processor
-    const filter: OperationalProcessorFilter = {
+    const filter: RelationalDbProcessorFilter = {
       branch: ["main"],
       documentId: ["*"],
       documentType: ["powerhouse/todo-list"],
@@ -84,7 +84,7 @@ export const todoProcessorProcessorFactory =
     // Create a namespaced store for the processor
     const store = await createNamespacedDb<TodoProcessorProcessor>(
       namespace,
-      module.operationalStore,
+      module.relationalStore,
     );
 
     // Create the processor
@@ -108,7 +108,7 @@ In the following you'll find an example where we store all the created and udpat
 ```ts
 type DocumentType = ToDoListDocument;
 
-export class TodoIndexerProcessor extends OperationalProcessor<DB> {
+export class TodoIndexerProcessor extends RelationalDbProcessor<DB> {
 
   static override getNamespace(driveId: string): string {
     // Default namespace: `${this.name}_${driveId.replaceAll("-", "_")}`
@@ -116,7 +116,7 @@ export class TodoIndexerProcessor extends OperationalProcessor<DB> {
   }
 
   override async initAndUpgrade(): Promise<void> {
-    await up(this.operationalStore as IOperationalStore);
+    await up(this.relationalDb as IBaseRelationalDb);
   }
 
   override async onStrands(
@@ -132,7 +132,7 @@ export class TodoIndexerProcessor extends OperationalProcessor<DB> {
       }
 
       for (const operation of strand.operations) {
-        await this.operationalStore
+        await this.relationalDb
           .insertInto("todo")
           .values({
             task: strand.documentId,
@@ -173,7 +173,7 @@ resolvers = {
         resolve: async (parent, args, context, info) => {
           const todoList = await TodoProcessor.query(
               args.driveId ?? "powerhouse", 
-              this.operationalStore
+              this.relationalDb
           )
             .selectFrom("todo")
             .selectAll()
@@ -197,7 +197,3 @@ resolvers = {
   ``` 
 
 
-  ### useOperationalStore Hook
-
-  ..... 
-

package/docs/academy/04-APIReferences/00-PowerhouseCLI.md

@@ -392,7 +392,7 @@ Examples:
   $ ph generate --drive-editor custom-drive-explorer                # Generate a custom drive editor
   $ ph generate -s MySubgraph                                       # Generate with a specific subgraph
   $ ph generate --skip-format                                       # Generate without formatting
-  $ ph generate --migration-file ./migrations.ts                    # Generate types for an Operational Processor
+  $ ph generate --migration-file ./migrations.ts                    # Generate types for an RelationalDB Processor
 ```
 
 ## Inspect

package/docs/academy/04-APIReferences/{04-OperationalDatabase.md → 04-RelationalDatabase.md}

@@ -1,10 +1,10 @@
-# Operational Database
+# Relational Database
 
-This page covers the operational database tools available in Powerhouse applications, providing type-safe database operations with real-time updates through PGlite integration.
+This page covers the relational database tools available in Powerhouse applications, providing type-safe database operations with real-time updates through PGlite integration.
 
 ## Overview
 
-The operational database layer gives you powerful tools to work with data in your Powerhouse applications. You get type-safe queries, real-time updates, and a simple API that feels familiar to React developers.
+The relational database layer gives you powerful tools to work with data in your Powerhouse applications. You get type-safe queries, real-time updates, and a simple API that feels familiar to React developers.
 
 **Key Benefits:**
 - 🔒 **Type-safe queries** with full TypeScript support
@@ -16,7 +16,7 @@ The operational database layer gives you powerful tools to work with data in you
 ## Quick Start
 
 <details>
-<summary>Setting up your first operational database query</summary>
+<summary>Setting up your first relational database query</summary>
 
 ### Step 1: Define your database schema
 
@@ -39,9 +39,9 @@ type MyDatabase = {
 ### Step 2: Create a typed query hook
 
 ```typescript
-import { createTypedQuery } from '@powerhousedao/reactor-browser/operational';
+import { createProcessorQuery } from '@powerhousedao/reactor-browser/relational';
 
-const useTypedQuery = createTypedQuery<MyDatabase>();
+const useTypedQuery = createProcessorQuery<MyDatabase>();
 ```
 
 ### Step 3: Use it in your component
@@ -95,32 +95,32 @@ function UserList() {
 
 ## Core Hooks
 
-### 1. createTypedQuery()
+### 1. createProcessorQuery()
 
 <details>
-<summary>`createTypedQuery<Schema>()`: Creates a typed query hook for your database schema</summary>
+<summary>`createProcessorQuery<Schema>()`: Creates a typed query hook for your database schema</summary>
 
 ### Hook Name and Signature
 
 ```typescript
-function createTypedQuery<Schema>(): TypedQueryHook<Schema>
+function createProcessorQuery<Schema>(): TypedQueryHook<Schema>
 ```
 
 ### Description
 
-Creates a typed query hook that provides type-safe database operations with live query capabilities. This is the main hook you'll use for most operational database operations in your components.
+Creates a typed query hook that provides type-safe database operations with live query capabilities. This is the main hook you'll use for most relational database operations in your components.
 
 ### Usage Example
 
 ```typescript
-import { createTypedQuery } from '@powerhousedao/reactor-browser/operational';
+import { createProcessorQuery } from '@powerhousedao/reactor-browser/relational';
 
 type AppDatabase = {
   users: { id: number; name: string; email: string };
   posts: { id: number; title: string; author_id: number };
 };
 
-const useTypedQuery = createTypedQuery<AppDatabase>();
+const useTypedQuery = createProcessorQuery<AppDatabase>();
 
 // Static query (no parameters)
 function useAllUsers() {
@@ -242,11 +242,11 @@ function DatabaseOperations() {
 - Always check if `db` is not null before using it
 - The database instance includes both Kysely methods and live query capabilities
 - Use this for direct database operations like inserts, updates, and deletes
-- For queries, prefer `createTypedQuery()` which provides better optimization
+- For queries, prefer `createProcessorQuery()` which provides better optimization
 
 ### Related Hooks
 
-- [`createTypedQuery`](#createtypedquery) - For optimized queries
+- [`createProcessorQuery`](#createProcessorQuery) - For optimized queries
 - [`useOperationalQuery`](#useoperationalquery) - For manual query control
 
 </details>
@@ -267,7 +267,7 @@ function useOperationalQuery<Schema, T, TParams>(
 
 ### Description
 
-Lower-level hook for creating live queries with manual control over the query callback and parameters. Most developers should use `createTypedQuery()` instead, but this hook is useful for advanced use cases.
+Lower-level hook for creating live queries with manual control over the query callback and parameters. Most developers should use `createProcessorQuery()` instead, but this hook is useful for advanced use cases.
 
 ### Usage Example
 
@@ -309,12 +309,12 @@ function UserCount() {
 ### Notes / Caveats
 
 - This hook doesn't include automatic parameter memoization
-- Use `createTypedQuery()` for better developer experience and optimization
+- Use `createProcessorQuery()` for better developer experience and optimization
 - Useful for cases where you need manual control over the query lifecycle
 
 ### Related Hooks
 
-- [`createTypedQuery`](#createtypedquery) - Recommended higher-level API
+- [`createProcessorQuery`](#createProcessorQuery) - Recommended higher-level API
 - [`useOperationalStore`](#useoperationalstore) - For direct database access
 
 </details>
@@ -332,7 +332,7 @@ You need to create queries that update automatically when search terms, filters,
 
 ### Solution
 
-The `createTypedQuery` hook automatically handles parameter changes and memoizes them using deep comparison:
+The `createProcessorQuery` hook automatically handles parameter changes and memoizes them using deep comparison:
 
 ```typescript
 function useSearchResults() {

package/docs/bookofpowerhouse/04-DevelopmentApproaches.md

@@ -28,7 +28,7 @@ These methodologies enhance collaboration, streamline workflows, and accelerate
     - This separation offers significant advantages:
         1. **Scalability**: Write and read models can scale independently, allowing Powerhouse to support large decentralized organizations without performance bottlenecks.
         2. **Maintainability**: By isolating business logic (commands) from query logic, developers can iterate on one without affecting the other, ensuring the system evolves efficiently.
-        3. **Flexibility**: Powerhouse supports multiple types of read models—such as operational databases, full-text search, and analytics—each tailored to specific organizational needs.
+        3. **Flexibility**: Powerhouse supports multiple types of read models—such as relational databases, full-text search, and analytics—each tailored to specific organizational needs.
         
 ### Event-driven Architectures (EDA)
     - Event-Driven Architecture (EDA) is a foundational element of Powerhouse’s software philosophy, designed to create responsive, scalable systems that support asynchronous workflows. In EDA, events represent meaningful changes or actions, such as “Document Updated” or “Contributor Added,” and these events trigger reactions across the system in real time.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@powerhousedao/academy",
-  "version": "3.3.0-dev.12",
+  "version": "3.3.0-dev.14",
   "homepage": "https://powerhouse.academy",
   "repository": {
     "type": "git",

package/sidebars.ts

@@ -111,7 +111,7 @@ const sidebars = {
       items: [
         "academy/APIReferences/PowerhouseCLI",
         "academy/APIReferences/ReactHooks",
-        "academy/APIReferences/OperationalDatabase",
+        "academy/APIReferences/RelationalDatabase",
         "academy/APIReferences/PHDocumentMigrationGuide",
       ],
     },