Merge branch 'release_4.5'

Author: kriszyp

docs/SUMMARY.md

@@ -122,6 +122,7 @@
   * [Storage Algorithm](technical-details/reference/storage-algorithm.md)
 * [Release Notes](technical-details/release-notes/README.md)
   * [Harper Tucker (Version 4)](technical-details/release-notes/4.tucker/README.md)
+    * [4.5.2](technical-details/release-notes/4.tucker/4.5.2.md)
     * [4.5.1](technical-details/release-notes/4.tucker/4.5.1.md)
     * [4.5.0](technical-details/release-notes/4.tucker/4.5.0.md)
     * [4.4.24](technical-details/release-notes/4.tucker/4.4.24.md)

docs/deployments/configuration.md

@@ -270,6 +270,10 @@ When true, Harper will verify certificates against the Node.js bundled CA store.
 
 Replication will first attempt to catch up using the audit log. If unsuccessful, it will perform a full table copy. When set to `false`, replication will only use the audit log.
 
+`shard` - _Type_: integer;
+
+This defines the shard id of this instance and is used in conjunction with the [Table Resource functions](../developers/replication/sharding#custom-sharding) `setResidency` & `setResidencyById` to programmatically route traffic to the proper shard.
+
 ***
 
 ### `clustering` using NATS

docs/developers/applications/caching.md

@@ -116,12 +116,12 @@ export class MyTableEndpoint extends MyTable {
 
 ### Subscriptions
 
-We can provide more control of an active cache with subscriptions. If there is a way to receive notifications from the external data source of data changes, we can implement this data source as an "active" data source for our cache by implementing a `subscribe` method. A `subscribe` method should return an asynchronous iterable that iterates and returns events indicating the updates. One straightforward way of creating an asynchronous iterable is by defining the `subscribe` method as an asynchronous generator. If we had an endpoint that we could poll for changes, we could implement this like:
+We can provide more control of an active cache with subscriptions. If there is a way to receive notifications from the external data source of data changes, we can implement this data source as an "active" data source for our cache by implementing a `subscribe` method. A `subscribe` method should return an asynchronous iterable that iterates and returns events indicating the updates. One straightforward way of creating an asynchronous iterable is by defining the `subscribe` method as an asynchronous generator. If we had an endpoint that we could poll for changes every second, we could implement this like:
 
 ```javascript
 class ThirdPartyAPI extends Resource {
 	async *subscribe() {
-		do {
+      setInterval(() => { // every second retrieve more data
 			// get the next data change event from the source
 			let update = (await fetch(`http://some-api.com/latest-update`)).json();
 			const event = { // define the change event (which will update the cache)
@@ -131,7 +131,7 @@ class ThirdPartyAPI extends Resource {
 				timestamp: // the timestamp of when the data change occurred
 			};
 			yield event; // this returns this event, notifying the cache of the change
-		} while(true);
+      }, 1000);
 	}
 	async get() {
 ...

docs/developers/replication/sharding.md

@@ -65,7 +65,12 @@ class MyTable extends tables.MyTable {
 ```
 
 ## Configuration for Static Sharding
-Alternatively, you can configure static sharding, where each node is assigned to a specific shard, and each record is replicated to the nodes in that shard based on the primary key. The `shard` is identified by a number. To configure the shard for each node, you can specify the shard number in the `replication`'s `routes` in the configuration:  
+Alternatively, you can configure static sharding, where each node is assigned to a specific shard, and each record is replicated to the nodes in that shard based on the primary key. The `shard` is identified by a number. To configure the shard for each node, you can specify the shard number in the `replication`'s `shard` in the configuration:
+```yaml
+replication:
+  shard: 1
+```
+Alternatively, you can configure the `shard` under the `replication` `routes`.  This allows you to assign a specific shard id based on the routing configuration.  
 ```yaml
 replication:
   routes:

docs/technical-details/reference/globals.md

@@ -113,6 +113,8 @@ class Origin {
 }
 Cache.sourcedFrom(Origin);
 ```
+- `login(username, password): Promise<void>` - This method can be called to start an authenticated session. The login will authenticate the user by username and password. If the authentication was successful, a session will be created and a cookie will be set on the response header that references the session. All subsequent requests from the client that sends the cookie in requests will be authenticated as the user that logged in and the session record will be attached to the request. This method returns a promise that resolves when the login is successful, and rejects if the login is unsuccessful.
+- `session` - This is the session object that is associated with current cookie-maintained session. This object is used to store session data for the current session. This is `Table` record instance, and can be updated by calling `request.session.update({ key: value })` or session can be retrieved with `request.session.get()`. If the cookie has not been set yet, a cookie will be set the first time a session is updated or a login occurs.
 - `_nodeRequest` - This is the underlying Node.js [`http.IncomingMessage`](https://nodejs.org/api/http.html#http_class_http_incomingmessage) object. This can be used to access the raw request data, such as the raw headers, raw body, etc. However, this is discouraged and should be used with caution since it will likely break any other server handlers that depends on the layered `Request` call with `Response` return pattern.
 - `_nodeResponse` - This is the underlying Node.js [`http.ServerResponse`](https://nodejs.org/api/http.html#http_class_http_serverresponse) object. This can be used to access the raw response data, such as the raw headers. Again, this is discouraged and can cause problems for middleware, should only be used if you are certain that other server handlers will not attempt to return a different `Response` object.
 

docs/technical-details/release-notes/4.tucker/4.5.2.md

@@ -0,0 +1,7 @@
+### HarperDB 4.5.2
+3/25/2025
+
+* For defined schemas, don't allow updates from remote nodes that could cause conflicts and repeated schema change requests
+* New harper-chrome docker container for accessing Chrome binaries for use with tools like Puppeteer
+* Improved rolling restart handling of errors with reaching individual nodes
+* Defined cleaner operation object to avoid accident leaking of credentials with logging

docs/technical-details/release-notes/README.md

@@ -4,6 +4,8 @@
 
 [Meet Tucker](4.tucker/tucker.md) Our 4th Release Pup
 
+[4.5.2 Tucker](4.tucker/4.5.2.md)
+
 [4.5.1 Tucker](4.tucker/4.5.1.md)
 
 [4.5.0 Tucker](4.tucker/4.5.0.md)