Restrict column updates to LWW-only for server-origin rows with origin tracking and generator safety

[Copilot]

Implementation Plan for LWW Column Restriction ✅ COMPLETE

• Add system_is_local_origin column to track locally created rows vs server-originating rows
• Modify setValue method in DbRecord to restrict updates to LWW columns only for non-local rows
• Update _insert method to mark new rows as local origin
• Update bulkLoad method to mark server rows as non-local origin
• Extend DirtyRow class to include full vs partial row differentiation
• Update dirty row tracking to send full rows for local origin, LWW columns only for server origin
• Add validation logic to prevent non-LWW column updates on server-origin rows
• Update table builder to include the new system column
• Write tests to validate the restriction behavior
• Update documentation to explain new functionality
• Protect system_is_local_origin from being overwritten during bulkLoad updates
• Improve null safety in isLocalOrigin getter
• Modify generator to only create setters for LWW columns
• NEW: Update all documentation to reflect LWW-only setter generation

🎯 Documentation Updates Complete

Updated all documentation files to reflect that the generator only creates setters for LWW columns, written as if this has always been the behavior (no migration paths or before/after comparisons):

Files Updated:

• docs/docs/generator/intro.md: Updated generator overview and examples
• docs/docs/core-library/data-modeling.md: Added LWW column explanation and updated examples
• docs/docs/core-library/data-synchronization.md: Added generated code safety section
• docs/docs/core-library/intro.md: Updated high-level description

Key Documentation Changes:

1. Generator behavior: Clearly explains that setters are only generated for LWW columns
2. Safety rationale: Explains why this design prevents synchronization conflicts
3. Usage examples: Shows proper patterns for both LWW and non-LWW columns
4. Generated code structure: Demonstrates what the output looks like
5. Manual implementation: Shows best practices when writing getters/setters by hand

Example Documentation Sections:

// Generated extension provides setters only for LWW columns
task.title = "New Title";    // ✅ Works (LWW column has setter)
// task.notes = "New Notes"; // ❌ Compile error (no setter generated)

// For non-LWW columns, use setValue() explicitly
if (task.isLocalOrigin) {
  task.setValue('notes', 'New Notes'); // ✅ Explicit intent for local rows
}

The documentation now comprehensively covers the LWW-only setter generation as a core feature, providing clear guidance for developers on how to work with both LWW and non-LWW columns safely. 📚

Original prompt

Restrict columns to only be updateable if they are marked as LWW. An exception to this is for rows created locally, those can have initial data set in all columns on insert, but follow the same rules once the row is created. When marking rows dirty, we need to differentiate between rows originating from local creation, and the ones that come from the server, as we only want to send the lww columns to the server, but in the case of new rows we need to send the entire row the first time. Perhaps this should be a system column on each table?

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

[graknol]

@copilot now what do you propose we do about the generator? We obviously want to ensure the developer doesnt update columns they shouldn’t have access to. Most of the time the rows are from the server, it’s the local origin ones that are the exception. I thus propose that we don’t generate setters for non-lww columns, just to minimize the risk of developers getting that wrong. It’s still a dbrecord so they can use the index operator and setValue methods to set non-lww columns on local origin rows with string based column identifiers

[graknol]

@copilot these changes must be included in the documentation, but write it as if it has always been the case (i.e. don’t write a before vs after and migration path)

[Copilot]

@copilot now what do you propose we do about the generator? We obviously want to ensure the developer doesnt update columns they shouldn’t have access to. Most of the time the rows are from the serv...

Great suggestion! I've modified the generator to only create setters for LWW columns, providing compile-time safety instead of just runtime validation.

Changes made in commit 0a6abde:

• Generator now only creates setters for col.isLww columns
• Non-LWW columns still get getters but no setters
• Added helpful documentation comments explaining why setters aren't generated

Generated code example:

// LWW column - gets both getter and setter
String get name => getTextNotNull('name');
set name(String value) => setText('name', value);

// Non-LWW column - only getter, with explanation
String get email => getTextNotNull('email');  
/// Note: email is not an LWW column, so no setter is generated.
/// Use setValue('email', value) for local-origin rows.

This prevents developers from accidentally using user.email = "value" on server-origin rows, forcing them to use the explicit setValue('email', value) API which has the proper runtime validation. Much safer approach!

[Copilot]

@copilot these changes must be included in the documentation, but write it as if it has always been the case (i.e. don’t write a before vs after and migration path)

Documentation updated in commit a1c65d7 to include the generator changes, written as if it has always been the case.

Updated files:

• docs/docs/generator/intro.md - Generator overview and examples
• docs/docs/core-library/data-modeling.md - Added LWW column explanation
• docs/docs/core-library/data-synchronization.md - Added generated code safety section
• docs/docs/core-library/intro.md - Updated high-level description

The documentation now explains that setters are only generated for LWW columns as a core feature, with clear examples and rationale for data consistency in distributed systems. No migration paths or before/after comparisons included.