Spike: Confirm Django's `loaddata` works for feature flag distribution

[khvn26]

We need to see if using Django's loaddata with results of dumporganisationdatatolocalfs is viable for manually distributing incremental changes to a separate Flagsmith installation.

[khvn26]

Tests in #6765.

Verdict

Using Django's loaddata with the output of dumporganisationtolocalfs works today for basic feature flag distribution — toggling flags, changing values, adding new features, adding segment overrides — as long as the organisation does not use v2 feature versioning, and no identities have traits or server-side API keys on the target.

Three categories of limitation need addressing before this is production-ready.

---

1. v2 feature versioning — blocked, low effort to fix

Symptom: loaddata raises DeserializationError for any organisation that has an environment with use_v2_feature_versioning = True.

Root cause: EnvironmentFeatureVersionManager (features/versioning/managers.py:16) inherits from SoftDeleteManager but is missing UUIDNaturalKeyManagerMixin. Every other exportable manager in the codebase includes this mixin. Without it, Django serialises FK references to EnvironmentFeatureVersion (on FeatureState.environment_feature_version and FeatureSegment.environment_feature_version) as a natural-key list ["<uuid>"], but the deserialiser cannot resolve the list back to an object because get_by_natural_key does not exist on the manager.

Fix: One-line change — add the mixin:

class EnvironmentFeatureVersionManager(UUIDNaturalKeyManagerMixin, SoftDeleteManager):

This follows the exact pattern of FeatureManager, FeatureStateManager, FeatureSegmentManager, and SoftDeleteExportableManager.

---

2. Missing get_by_natural_key on Trait and EnvironmentAPIKey — blocked for orgs that use these, low-to-medium effort

Symptom: loaddata raises IntegrityError when the target database already contains the same trait or API key.

Root cause: Both models define natural_key() (used during serialisation) but their managers lack get_by_natural_key() (needed during deserialisation). Without it, loaddata always attempts an INSERT rather than an UPDATE, hitting unique constraints.

Model	natural_key() returns	Unique constraint
Trait	(trait_key, identifier, api_key)	(trait_key, identity_id)
EnvironmentAPIKey	(key,)	key

Fix: Add get_by_natural_key to each model's manager. Unlike the v2 versioning fix (which is just adding the existing UUID mixin), these need custom implementations since they use non-UUID natural keys:

# Trait manager
def get_by_natural_key(self, trait_key, identifier, api_key):
    return self.get(
        trait_key=trait_key,
        identity__identifier=identifier,
        identity__environment__api_key=api_key,
    )

# EnvironmentAPIKey manager
def get_by_natural_key(self, key):
    return self.get(key=key)

Both are small changes, but Trait currently uses Django's default manager, so a custom manager class needs creating.

A more viable alternative would be to have an ability to exclude identities from dumporganisationdatatolocalfs completely.

---

3. Deletions not propagated — inherent loaddata limitation, medium effort for a workaround

Symptom: Objects deleted on the source still exist on the target after re-loading. loaddata only upserts — it never removes rows absent from the fixture.

Impact by deletion strategy:

Soft-deletable models (row kept with deleted_at set):
Organisation, Subscription, Project, Segment, SegmentRule, Condition, Feature, FeatureState, FeatureStateValue, EnvironmentFeatureVersion, Environment, DataDogConfiguration, NewRelicConfiguration, SlackConfiguration, HeapConfiguration, MixpanelConfiguration, SegmentConfiguration, RudderstackConfiguration, WebhookConfiguration.

For these, loaddata can "undelete" a soft-deleted record (by setting deleted_at back to null), but it cannot soft-delete a record that is absent from the dump. Stale soft-deleted records on the target will remain active.

Hard-deletable models (row removed permanently):
InviteLink, OrganisationWebhook, Tag, SlackEnvironment, EnvironmentAPIKey, Webhook, Identity, Trait, MultivariateFeatureOption, FeatureSegment, MultivariateFeatureStateValue, MetadataField, MetadataModelField, MetadataModelFieldRequirement, Metadata.

Once deleted on the source, these are simply absent from the dump. loaddata will not remove the corresponding rows on the target.

Possible fix: A separate cleanup step that diffs the dump against the target DB and removes/soft-deletes stale records. This is outside the scope of loaddata and would need a custom management command.

---

Summary of work required

Issue	Blocker?	Effort	Scope
v2 versioning DeserializationError	Yes, for v2 orgs	~1 line + test update	features/versioning/managers.py
Trait IntegrityError on reload	Yes, for orgs with traits	Small — new manager class + method, or exclude identities entirely	environments/identities/traits/
EnvironmentAPIKey IntegrityError on reload	Yes, for orgs with server-side keys	Small — add method to manager	environments/models.py
Deletions not propagated	No (acceptable for append-only use)	Medium — custom diff/cleanup command	New management command

[khvn26]

Created:

• Epic: Air-gapped environment readiness for loaddata #6767: essential tasks to support the use-case.
• Some Django models are not soft-deletable #6770: a nice-to-have improvement to the platform.