Document Timestamps

Is there a way to find the timestamp of the last edit made to a Document?

I also am not seeing anything for this from the api docs

Yeah

I want to know if something's been updated while my module is disabled

Iiiinnnnteresting

Oof, that's a brain teaser

Spitballing from left-field:

You could generate a hash of some sort from the document data and store that as a flag. It would theoretically not be as heavy as storing the whole thing.

Is this something you want to do a "is anything different" on ready or would "is this particular thing different" when that particular thing is opened?

because I can't imagine generating and comparing a hash for every document on ready would be very performant

I'm brainstorming a world update manager, so that content providers can provide updates to content without the user having to overwrite the entire world

It has an export function which creators can initiate whenever they are about to release a new version. It would create a hash of every document and save that to the worlds flags.
Then, whenever that module is enabled during a world's load on a client, it will check for those static world flags and compare them to hashes of the current version. It can prompt the user if it wants to get the modified version, or delete the old version, etc.

oof

Ok, dumb question

"Does it matter if the document has changed?"

@Surge join us

Publisher pushes an update to the world. Doesn't the user want to update to that new version?

Picking some things to not update makes sense

The timestamps were to be able to know whether the Document has been deleted and readded

Here's why I ask if it matters:

Without needing to generate hashes, "all this updater has to do" is keep track of a Document version number.

If the version number increments, it prompts the user if they want to update.

That might work, yes

Indeed, I feel silly for overlooking a simple solution like this

Yeah, using the db files makes this an external (non-module) tool, so not a fan

We just tell Creators that all updates must be versioned using semver

The issue is managing what happens if the module is disabled

No, that would defeat the purpose

Maybe we only create hashes on load for Documents whose ID is in the flags with the same version

Yes, but it would become confusing for users if they ever disable it for any reason and then have their changes overwritten on update

i.e. it would mean that changes made with the module enabled are the only ones not always overwritten

I have to step out for an appointment, but would love to continue brainstorming this later with y'all

A mix of hashing and version numbers would avoid this: https://discord.com/channels/732325252788387980/875016328786903041/875025603504504832

We could test how it is on performance and perhaps provide a performance option for users which requires the module to never be disabled. This could be enabled or disabled at the user's whim even

Or maybe instead of always running on load, we add a button to run the checks. I.e. "Update World"

IMO a User knows what scenes they've changed and what changes they care to keep vs override with an update.

Making these updates not automatic is important. Having a user flow (prompted or otherwise) which asks the user which updated documents they want to import would be pretty sufficient in my mind.

Although... My main concern with the hash idea was how performant that would be on world load. There's already a lot going on during world load (including migrations for system/module updates usually) and IMO it would be smarter to ask the user to start an update process.

If the hash + compare was only done during the 'update flow', and especially only for the documents whose versions incremented, it would help immensely with the performance.

Semver is kinda overkill IMO. The world updater (and the user doing the import) only needs to know that a document has been changed, the magnitude of that change on a per-document level is more or less irrelevant.

Not semver for the individual Documents, just for the world itself. i.e. the version in the manifest, etc.

Yes, we don't want it completely automatic and there will be a prompt before each change, but I do want avoid implementing git merge which is what is in the Epic on GitLab

gotchya

If you want to put more eyes on this kind of thing in the future, don't hesitate to make a workgroup and pull people in to get more feedback. One of the things we do here is identify pain points and distill many devs feedback into one "League Proposal".

Is there a functional difference between this thread and a workgroup?

Another thing about this is that I've participated in this discussion on two other servers, so not everything/everyone is in one spot

making a League proposal, although I don't know exactly how to do that

#158-world-updating