Consider Keystone-compatible default value handling for text fields

[borisno2]

Summary

When migrating from Keystone to OpenSaaS Stack, Keystone's automatic empty string defaults for text fields are removed, which could cause behavioral changes in migrated applications.

Keystone Behavior vs OpenSaaS Behavior

Keystone: Text fields without explicit defaults get empty string '' as default:

firstName String @default("")
surname String @default("")
phone String @default("")

OpenSaaS Stack: Text fields without validation.isRequired are nullable, no default:

firstName String?
surname String?
phone String?

Migration Impact

The migration drops all empty string defaults:

ALTER COLUMN "firstName" DROP DEFAULT;
ALTER COLUMN "surname" DROP DEFAULT;
ALTER COLUMN "phone" DROP DEFAULT;
ALTER COLUMN "streetAddress" DROP DEFAULT;
ALTER COLUMN "suburb" DROP DEFAULT;
-- ... many more string fields

Why This Matters

1. Application Logic: Code may rely on empty strings vs NULL

   // This breaks if field is NULL instead of ""
   if (user.firstName === "") { /* ... */ }

2. Form Handling: Form libraries treat empty strings and null differently

   defaultValues: {
     firstName: user.firstName ?? ""  // Need explicit coalescing
   }

3. Database Queries: SQL queries behave differently

   -- This won't match NULL values
   SELECT * FROM "Account" WHERE "firstName" = '';

Proposed Solutions

Option 1: Documentation (Minimum)

Document the behavioral difference clearly for migrating users.

Option 2: Configuration Option

Add option to match Keystone's behavior:

// opensaas.config.ts
export default {
  db: {
    textFieldDefaults: 'keystone' | 'nullable'  // default: 'nullable'
  }
}

Option 3: Field-Level Option

firstName: text({
  db: {
    defaultEmpty: true  // Generates @default("")
  }
})

Priority

Medium - Not a blocker but can cause subtle bugs. Lower priority than other migration issues.