Wrap up migration: add example app

[zippy]

As an app developer I want an example of how migration works and can be used.

[thedavidmeister]

Here is the summary of my discussion with @zippy on this topic

What system level validation/logic and what application level validation/logic should be applied to migration entries is also an open question to some extent, e.g.:

• when should a developer bridge and when should they migrate?
• what relationships between chains are allowed?
  • one to one, one to many, many to many
  • circular references between chains allowed or DAG only?
• who can migrate whom?
  • e.g. could an "admin" boot everyone and force a migration to a new version? (the ability to do this could be a hard security requirement in many contexts)
  • is this the "code governance" that @artbrock and i talked about a while back?
• in a "migration" is data copied or simply referenced in situ?
  • do we allow side effects in this process, or is it purely functional primitives (e.g. map/reduce/filter)
  • in the case where side effects are not allowed and data is copied, note that copying data is simply a pragmatic performance v. storage tradeoff at that point
• do we allow "old" code to execute against "old" data or must data always be "brought forward" to the latest version?
  • executing legacy code for legacy data is a holy grail for some, and a security/organisational nightmare for others...

There's also the "chicken and egg" problem to tackle, where migration logic must be written into an app before either the migration destination or reason is known. That is to say, writing the migration when you need it (how you'd do things in a traditional development cycle) is too late because any zome additions you make to manage the migration would immediately fork you out of the network you're trying to provide a migration for...

Somehow we have to show how a fully parameterised "context free migration" can be achieved without loss of:

• flexibility
• security
• user experience

Rather than getting lost in the infinite here, we've decided to start applying the basic foundations we have to some use cases and iterate based on what we learned. The examples will allow us to start developing "best practices" and can be documented and shown to people. Hopefully the examples will also give us context to start chipping away at the above (and probably raise more q's along the way).

The first 3 clear use-cases discussed are:

• transient app management: tracking data across short-lived apps (e.g. a chat room)
• the "traditional" migration: massage the shape of data to align with code changes
• "in situ" data management: janitorial tasks for chains (e.g. log rotation)

I'm going to start looking at the first use-case, transient app management. Wish me luck! 😄

[thedavidmeister]

ok, transient app management is probably the most complex use-case

i think it's counterproductive to try and jump from zero to chat room in one step

end goal: build a voting app on HC where users can migrate into and out of "voting rooms"

a "voting room" is a simple case of a chat room

• opening the room allows votes to be cast
• closing the room prevents votes from being cast
• the user that opens the room can close it for everyone
• users can post a simple boolean true to vote on some system entity
• the votes are tallied in real time (ish)

step 1:

toy example:

• bidirectional migration
• two identical apps (other than UUID)
• app level logic prevents commits to a closed chain
• UI periodically pushes commits to both apps, reports success and error based on migration status
• UI allows the user to migrate between apps

tracking this example at #50

[thedavidmeister]

step 2:

toy example:

• unidirectional migration
• multiple identical apps (other than UUID)
• semantic versioning
• apps dynamically generated through UI
• app logic prevents commits to old versions
• UI allows user to "upgrade" app (bumps semantic version without real changes to any code)

[ddd-mtl]

The DAO code in benchmarks has 'congress' which is like a voting room.

For another use-case, how about a GDPR case where a user leaves the app and wants his data removed. I think that's possible only with migration.

[thedavidmeister]

@ddd-mtl mmmmmmmm indeed, good ideas :D

[zippy]

I've started an article in the In Progress section of Articles on developer.holochain.net.