Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Always assign UUID #354

Merged
merged 8 commits into from
Sep 9, 2024
Merged

Always assign UUID #354

merged 8 commits into from
Sep 9, 2024

Conversation

MikkelPaulson
Copy link
Collaborator

This is a working change to ensure that the Thing object (as well as subtypes Npc and Place) always have UUIDs present whether or not they have been saved to the journal. This is done by moving all data fields from Npc and Place into substructs NpcData and PlaceData, respectively. Then the times when we refer to a lump of data, we can use NpcData (such as when applying a diff), while when we want to refer to an entire record, we can use Npc.

Ultimately I expect this to have the benefit of clarifying when we're talking about a Thing vs. when we're only talking about its data.

@MikkelPaulson MikkelPaulson marked this pull request as draft August 20, 2024 20:55
@MikkelPaulson
Copy link
Collaborator Author

@ChrisRenfrow Continues to be a small change.

Copy link

cloudflare-workers-and-pages bot commented Aug 22, 2024

Deploying initiative-sh with  Cloudflare Pages  Cloudflare Pages

Latest commit: d5224f6
Status: ✅  Deploy successful!
Preview URL: https://32d77678.initiativesh.pages.dev
Branch Preview URL: https://always-assign-uuid.initiativesh.pages.dev

View logs

@MikkelPaulson MikkelPaulson force-pushed the always-assign-uuid branch 4 times, most recently from ca9456d to e5a9f48 Compare September 3, 2024 00:34
@MikkelPaulson MikkelPaulson force-pushed the always-assign-uuid branch 2 times, most recently from 06af757 to 868b34b Compare September 4, 2024 15:12
The compiler complains about taking references to static mut. We're only
using it ephemerally in tests, so safety isn't a big concern, but
avoiding build errors is.
Since a UUID isn't guaranteed valid anyway, there's no point in having a
newtype for Npc vs. Place UUIDs, and it just adds an extra layer of
From/Into.
We still need a way to represent a blob of data that is not a complete
Thing, for the purposes of undo/redo, (re)generating information, etc.
This is now done by following the pattern of Thing { uuid, data }, where
all meta fields are contained within data. (Parallels of this pattern
have also been created specifically for Npc and Place.)

To keep this change "small", the `uuid` property of `Thing` remains
`Option`al; I'll tighten up the distinction between `Thing` and
`ThingData` in a future commit.
@MikkelPaulson MikkelPaulson linked an issue Sep 4, 2024 that may be closed by this pull request
@MikkelPaulson MikkelPaulson marked this pull request as ready for review September 4, 2024 15:29
@MikkelPaulson MikkelPaulson force-pushed the always-assign-uuid branch 4 times, most recently from ab1e8f1 to b15db46 Compare September 9, 2024 15:50
* Change the type of Thing.uuid, Npc.uuid, and Place.uuid from
  Option<Uuid> to Uuid
* Add an is_saved flag to the above to serve the purpose that the None
  was previously serving *in certain circumstances* (ie. when the Thing
  was saved to the recent list rather than the journal)
* Rewote the repository layer to operate on a ThingData when creating
  Things and a UUID in most other cases. The repository is also
  responsible for issuing UUIDs except in specific circumstances (undo
  or while importing).
* The tests, oh god the tests.
Boolean flag was used to indicate if a Thing was currently located in
the journal or temporarily stored in recent entries. This wasn't ideal
because the data saved to journal/recent included the flag, so there was
a lot of bespoke logic to ensure (maybe unsuccessfully) that the flag
was never accidentally saved to the wrong place.

Instead, we wrap the Thing in an ephemeral wrapper called Record,
making the saved-ness of the Thing accessible through the return value
if needed but without bothering to include it in either the stored data
or code that interacts with the data directly without regard for where
it came from.
Turns out Clippy has Opinions about clean code in tests too!
Replace the into_(place|npc)(_data)? functions with implementations of
the TryFrom trait, because that's what it's for.
Rust 1.81.0 stabilizes #[expect] annotations, which function like
 #[allow] but fail in the case that the lint does not occur. This
updates all existing uses of #[allow] to either use #[expect], or
removes unnecessary lint overrides altogether.
@MikkelPaulson MikkelPaulson merged commit 8bd6629 into main Sep 9, 2024
3 of 4 checks passed
@MikkelPaulson MikkelPaulson deleted the always-assign-uuid branch September 9, 2024 19:00
MikkelPaulson added a commit that referenced this pull request Oct 30, 2024
GitHub action was updated to apply Clippy to tests in #354, but the
test.sh script was not updated. This is now fixed.
MikkelPaulson added a commit that referenced this pull request Oct 31, 2024
GitHub action was updated to apply Clippy to tests in #354, but the
test.sh script was not updated. This is now fixed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Ensure that Things always have a UUID
1 participant