From c52b3a4b1c572ae4ccb333826e3975d986205fbe Mon Sep 17 00:00:00 2001
From: manu-sj <manu.joseph@logicalclocks.com>
Date: Mon, 3 Aug 2026 20:58:05 +0200
Subject: [PATCH 1/3] [FSTORE-1903] Backwards compatibility and upgrade tests
 for Feature Logging https://hopsworks.atlassian.net/browse/FSTORE-1903

FSTORE-1871 reworked feature logging around a single combined logging
feature group, while feature views that enabled logging before the
upgrade keep their frozen pre-1871 pair of feature groups. Running
model deployments and batch services embed old Python clients that
must keep logging against those legacy feature groups with zero
downtime, and new clients must keep working against them too.

Document the upgrade compatibility contract on the feature logging
user guide: pre-upgrade feature views keep working for old and new
clients alike, purging converts them to the combined layout, enabling
logging on new feature views requires a 4.6 or later client, and
positional log() calls written for the pre-4.6 signature keep working
on pre-upgrade feature views with the keyword form as the migration
target. Also correct the enablement section, which still described the
pre-4.6 pair of logging feature groups.

Signed-off-by: Manu Sathyarajan Joseph <manu.joseph@logicalclocks.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---
 .../fs/feature_view/feature_logging.md        | 26 +++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/docs/user_guides/fs/feature_view/feature_logging.md b/docs/user_guides/fs/feature_view/feature_logging.md
index c3e01e97a7..f51a69db4c 100644
--- a/docs/user_guides/fs/feature_view/feature_logging.md
+++ b/docs/user_guides/fs/feature_view/feature_logging.md
@@ -298,3 +298,29 @@ feature_view.delete_log()
 ```
 
 Restart serving revisions after recreating a logging group so they load its new schema and destination.
+
+## Upgrade Compatibility with Pre-4.6 Feature Logging
+
+Hopsworks 4.6 changed the feature logging layout: transformed and untransformed features are logged into one combined feature group instead of a separate pair, labels are logged as `predicted_<label>` columns, and the model identity is stored in `model_name` and `model_version` columns instead of a single `hsml_model` column.
+
+Feature views that enabled logging before the upgrade keep their original pair of logging feature groups unchanged.
+Model deployments and batch jobs that still run a pre-4.6 client keep logging to those feature views without any code change or downtime.
+Clients from 4.6 onwards also keep working against them: predictions and the model identity are written into the original columns, and `feature_view.read_log(model_name=..., model_version=...)` filters on the original `hsml_model` column.
+Calling `feature_view.delete_log()` on such a feature view deletes the original pair and recreates the logs in the combined layout on the `realtime` transport, or on the `job` transport with `feature_view.delete_log(transport="job")`.
+A deployment that still runs a pre-4.6 client cannot write to the recreated group and its logs are lost, so update the deployment's environment to a 4.6 or later client before deleting the log.
+
+Enabling logging on a feature view created after the upgrade requires a 4.6 or later client.
+A pre-4.6 client cannot produce the combined layout, so its `feature_view.log(...)` calls against such feature views fail instead of writing incomplete rows.
+
+The first positional parameter of `feature_view.log()` changed in 4.6 from `untransformed_features` to `logging_data`.
+On feature views with the pre-4.6 pair of logging feature groups, positional calls written for the old signature are detected and keep working.
+
+```python
+# Positional call style written for pre-4.6 clients, still working on
+# feature views that predate the upgrade:
+feature_view.log(features, predictions)
+
+# Equivalent call that works on every feature view; use this form when
+# migrating code to a 4.6 or later client:
+feature_view.log(features, predictions=predictions)
+```

From 2e117bf845df670af7b308bcd851c2df00677613 Mon Sep 17 00:00:00 2001
From: manu-sj <manu.joseph@logicalclocks.com>
Date: Thu, 3 Sep 2026 14:55:34 +0200
Subject: [PATCH 2/3] [FSTORE-1903] Backwards compatibility and upgrade tests
 for Feature Logging https://hopsworks.atlassian.net/browse/FSTORE-1903

Pre-PR review fix for the FSTORE-1903 documentation: two sections of
the feature logging guide still described the pre-4.6 layout.

The materialize and delete sections described a pair of logs and the
transformed argument as selecting one of them. They now state what
the argument does on each layout: on the pre-4.6 pair delete_log()
replaces the pair as a whole whichever slot is named, and on the
combined layout there is a single log, so
materialize_log(transformed=...) makes no difference and
delete_log(transformed=True) does nothing.

Signed-off-by: Manu Sathyarajan Joseph <manu.joseph@logicalclocks.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
---
 docs/user_guides/fs/feature_view/feature_logging.md | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/docs/user_guides/fs/feature_view/feature_logging.md b/docs/user_guides/fs/feature_view/feature_logging.md
index f51a69db4c..b1f85d8514 100644
--- a/docs/user_guides/fs/feature_view/feature_logging.md
+++ b/docs/user_guides/fs/feature_view/feature_logging.md
@@ -283,14 +283,15 @@ Those logs are covered by the commit job's or the materialization job's own exec
 ## Deleting Logs
 
 When log data is no longer needed, you might want to delete it to free up space and maintain data hygiene.
-This operation deletes the feature groups and recreates new ones.
+This operation deletes the logging feature group and recreates a new one.
 Scheduled materialization job and log timeline are reset as well.
 Pass `transport="realtime"` or `transport="job"` to recreate the logging group for the other transport.
 
 ### Delete Logs
 
 Remove all log entries.
-The `transformed` selector applies only to older feature views with separate logging groups.
+On a feature view that still has the pre-4.6 pair of logging feature groups, `delete_log()` deletes both and recreates the log in the combined layout; passing `transformed=True` or `transformed=False` does the same, because the pair can only be replaced as a whole.
+On the combined layout, `delete_log(transformed=True)` has nothing to delete and does nothing.
 
 ```python
 # Delete all log entries

From 7924ddec9d7cb6ecc7ab5eca23b7facd3257021e Mon Sep 17 00:00:00 2001
From: manu-sj <manu.joseph@logicalclocks.com>
Date: Wed, 7 Oct 2026 11:27:28 +0200
Subject: [PATCH 3/3] [FSTORE-1903] Backwards compatibility and upgrade tests
 for Feature Logging https://hopsworks.atlassian.net/browse/FSTORE-1903

Address review round 1 on the feature logging guide.

State that on feature views with the pre-4.6 logging groups,
model_name and model_version must be passed together to read_log and
log, and why a name-only filter cannot be expressed on hsml_model.

Signed-off-by: Manu Sathyarajan Joseph <manu.joseph@logicalclocks.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---
 docs/user_guides/fs/feature_view/feature_logging.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/docs/user_guides/fs/feature_view/feature_logging.md b/docs/user_guides/fs/feature_view/feature_logging.md
index b1f85d8514..c2f8ecc4df 100644
--- a/docs/user_guides/fs/feature_view/feature_logging.md
+++ b/docs/user_guides/fs/feature_view/feature_logging.md
@@ -307,6 +307,8 @@ Hopsworks 4.6 changed the feature logging layout: transformed and untransformed
 Feature views that enabled logging before the upgrade keep their original pair of logging feature groups unchanged.
 Model deployments and batch jobs that still run a pre-4.6 client keep logging to those feature views without any code change or downtime.
 Clients from 4.6 onwards also keep working against them: predictions and the model identity are written into the original columns, and `feature_view.read_log(model_name=..., model_version=...)` filters on the original `hsml_model` column.
+On these feature views, `model_name` and `model_version` must be passed together, both to `read_log()` and to `log()`, and passing only one raises an error.
+The `hsml_model` column stores `<model_name>_<model_version>` as one value, so a filter on the name alone would be a prefix match, which cannot express "any version" because `_` is a wildcard and sibling model names share the prefix.
 Calling `feature_view.delete_log()` on such a feature view deletes the original pair and recreates the logs in the combined layout on the `realtime` transport, or on the `job` transport with `feature_view.delete_log(transport="job")`.
 A deployment that still runs a pre-4.6 client cannot write to the recreated group and its logs are lost, so update the deployment's environment to a 4.6 or later client before deleting the log.