Class SettingsAssetByIdDraftCommit
The by-Id-in-folder sibling of SettingsAssetDraftCommit: the one shared "resolve-or-create the settings asset by Id within a folder, then commit a draft's every field onto it" sequence for a creator whose asset resolves by Id within a folder rather than by an explicit or project-wide-singleton path (SettingsAssetDraftCommit covers that case instead). Serenity.InputGateway.Installation.Editor.Builder.PlayerInputCreator and Serenity.GameMode.Installation.Editor.Builder.GameModeSettingsCreator both call this for every asset type they author, so an update-in-place run always writes onto a draft seeded from the asset an existing Id resolves to, never onto hardcoded field defaults.
Every caller still owns its OWN Serenity.Global.Infrastructure.Editor.SerenityAssetCreationTransaction, its own commit/rollback, its own Addressables module label, and any cross-asset wiring (a Routing asset's reference to its Device Filter/Join Gate) — this collaborator only resolves the settings asset and writes the draft onto it, exactly the part that never differs between callers.
Inherited Members
Namespace: Serenity.StructuredPersistence.Infrastructure.Editor.Authoring
Assembly: Serenity.UnityStructuredPersistence.Infrastructure.Editor.dll
Syntax
public static class SettingsAssetByIdDraftCommit
Methods
ResolveAndCommit<TSettings>(TSettings, string, string, string, SerenityAssetCreationTransaction)
Resolves the existing TSettings asset whose Id equals id
within folderPath (or plans a new one there, refusing instead of overwriting a
different asset already at the planned path — see
ResolveOrCreateByIdInFolder<TSettings>(string, string, string, SerenityAssetCreationTransaction, out bool)), then commits
draft onto it through the shared Serenity.StructuredPersistence.Infrastructure.Editor.Authoring.SettingsAssetCommitCore.Commit``1(``0,``0,``0,System.String,Serenity.Global.Infrastructure.Editor.SerenityAssetCreationTransaction)
tail — identity rule, field copy, and the update-only disk verification are identical to
SettingsAssetDraftCommit's own commit, so only the resolution step (by Id within a
folder, here, vs. an explicit/singleton path there) differs between the two. Tracks the
resolved/created asset on transaction, but never commits or rolls it back — that
stays the caller's own responsibility, since only the caller knows what else belongs in the same
transaction.
Declaration
public static SettingsAssetDraftCommitOutcome ResolveAndCommit<TSettings>(TSettings draft, string folderPath, string id, string fileNameFallback, SerenityAssetCreationTransaction transaction) where TSettings : ScriptableObject, IFoundationSettings
Parameters
| Type | Name | Description |
|---|---|---|
| TSettings | draft | Every field to write: an already-seeded scratch draft from an existing asset for an update-in-place run, or a freshly populated one for a create. Its own Guid is ignored — this call owns identity regardless of what the draft already carried. |
| string | folderPath | Folder searched for an existing same-Id asset, and that a brand-new asset is created under. |
| string | id | The Id resolved within |
| string | fileNameFallback | File name used when |
| SerenityAssetCreationTransaction | transaction | The caller's own transaction — this call tracks the resolved/created asset on it. |
Returns
| Type | Description |
|---|---|
| SettingsAssetDraftCommitOutcome |
Type Parameters
| Name | Description |
|---|---|
| TSettings |