I'm having some issues with my GridDB Cloud setup. I've got these massive time-series containers – we're talking terabytes of data – and my application is constantly evolving. This means I frequently need to add new columns to these existing, very active containers. The absolute nightmare scenario is causing any downtime for my ongoing data ingestion and queries.

I've dug through the GridDB docs and I'm familiar with basic ALTER TABLE operations. For simple, non-critical stuff, I've used gs_sh to add columns. For example, adding a sensor_location column looks pretty straightforward:

-- This is what I'd run in gs_sh or via a SQL client
ALTER TABLE MyLargeTimeSeriesContainer ADD COLUMN sensor_location STRING;

But here's where the real problem starts: after I run that ALTER TABLE statement, my Python application (which is constantly streaming data) often chokes. It's like the client-side schema cache gets out of sync, or it suddenly expects a value for the new column that it wasn't providing before. This leads to nasty errors and effectively, downtime for my ingestion pipeline.

Here's a simplified Python snippet illustrating the kind of issue I run into:

import griddb_python as griddb
import datetime
import time


container_name = 'MyLargeTimeSeriesContainer'

try:
    container = store.get_container(container_name)
    if container is None:
        print(f"Error: Container '{container_name}' not found. Exiting.")
        exit()
except Exception as e:
    print(f"Critical error getting container '{container_name}': {e}")
    exit()

# Imagine this loop is constantly running, inserting data
for i in range(10):
    try:
        timestamp = datetime.datetime.now(datetime.timezone.utc)
        value = 100.0 + i # Just some dummy data
        # This is the ORIGINAL insertion logic, BEFORE ALTER TABLE
        container.put(timestamp, value)
        print(f"[{i}] Inserted data with old schema: {{timestamp}}, {{value}}")
        time.sleep(0.1) # Simulate continuous ingestion
    except Exception as e:
        print(f"[{i}] ERROR: Failed to insert data with old schema: {e}")
        print("This is the error I'm trying to avoid during schema evolution!")
        # How do I gracefully handle this? Do I need to re-initialize the container object?
        # Or force the client to refresh its schema awareness without restarting the whole app?
        break # Stop on first error for demonstration

# If I then run ALTER TABLE ADD COLUMN sensor_location STRING;
# and my app tries to insert again with the old 'put' signature, it breaks.
# If I adapt my code to:
# container.put(timestamp, value, "Building A")
# ... how do I deploy this new code without downtime while the old schema is still active?

What are the battle-tested strategies and best practices for adding new columns to large, active TimeSeries containers in GridDB Cloud with truly minimal or zero downtime? I'm particularly interested in how client applications (like my Python streamer) can gracefully handle these schema updates without crashing or requiring a full restart.

I'm really hoping for some detailed architectural patterns, insights into GridDB Cloud's internal schema update mechanisms, or even external tools/approaches that can help me achieve this.