Migrations

[pipermerriam]

Work in progress for #106

TODO list

• disect the various Operation classes so that they aren't single method giants
• contract library linking
• figure out better way to do receipts and writing them to the registrar
• figure out how to use the registrar for things like "Where is contract X".
• Actual filesystem stuff for migration files.
• Gas estimates should move down into the web3.eth.contract.deploy() and web3.eth.contract.transact() methods. (https://github.com/pipermerriam/web3.py/pull/53)
• Implement populus.chain.Chain class for use when the user wants to run their own blockchain client.
• Implement populus migrate command.
• Update deploy command to make use of migration utils.
• Update deploy command to link against already deployed instances of necessary libraries that are found in the registrar.
• Redo populus.migrations.writer so that it handles imports. This is likely changing the semantics of how writing works so that there is a serialization step, followed by a writing the actual migration contents.
• Extract duplicate code in migrate and deploy into a helper that is well tested. (pick chain, pick account, unlock account, write new defaults).
• Figure out if the PopulusConfig object in the pytest plugins is necessary. I suspect that everything it does is now handled by the Project and project.config stuff.
• Write test coverage for pytest plugins.
• Update documentation for deployment
• Write documentation for migrations
• Update documentation for populus chain run
• Update documentation for pytest plugins.
• Write documentation for populus.chain.Chain objects
• Write documentation for populus.project.Project object
• Write documentation for project configuration

What was wrong?

TODO

How was it fixed?

TODO

Cute Animal Picture

put a cute animal picture here.

TODO

[pipermerriam]

Currently, this is what a migration file is likely to look like.

from populus import migrations


function a_custom_migration_fn(web3, compiled_contracts, **kwargs):
    ...  # do whatever you want here.


class Migration(migrations.Migration):
    migration_id = '0001_initial'
    dependencies = []

    operations = [
        migrations.DeployContract('Thrower', ['some-constructor-argument']),
        migrations.TransactContract('Thrower', 'transferFrom', [...some-arguments]),
        migrations.SendTransaction({'from': '0xabcd1234', 'to': '0xabcd1234', 'value': 54321}),
        migrations.RunPython(a_custom_migration_fn),
    ]

    compiled_contracts = {
        'Thrower': {
            'code': "0x606060405260405160208060318339506080604052518015601e576002565b50600680602b6000396000f3606060405200",
            'code_runtime': "0x606060405200",
            'abi': [
                {
                    "inputs": [{"name": "shouldThrow", "type": "bool"}],
                    "type": "constructor",
                },
            ],
        },
    }

[pipermerriam]

@miohtama curious whether you have a minute to look this over and give any preliminary feedback you might have on it.

[miohtama]

Can you give me links to existing migration frameworks and some background story? I know the concept of database migrations from SQLAlchemy, Django, etc. and I am curious if we are using the word migration in similar context here.

[pipermerriam]

I stole the concept from truffle so you can see their implementation in the
truffle documentation. Also I plan to implement a migration contract to
keep track of migration state and a registrar contract to keep track of
already deployed contract addresses.

On Wed, Aug 3, 2016, 11:57 AM Mikko Ohtamaa notifications@github.com
wrote:

Can you give me links to existing migration frameworks and some background
story? I know the concept of database migrations from SQLAlchemy, Django,
etc. and I am curious if we are using the word migration in similar context
here.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/pipermerriam/populus/pull/113#issuecomment-237309507,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAyTglEbah60ecPjDSRaLEYJjSDXZxG5ks5qcNWUgaJpZM4Ja6dQ
.

[miohtama]

Perfect! Learning registrar contracts is one thing on my TODO list.

[pipermerriam]

@miohtama this is the initial version I hammered out last night. It's really more of an immutable key/value store than a registrar. The idea is as follows.

In migration 0002_deploy_Math_contract which deploys some contract named Math, the Migration would register the following information within the registrar contract.

registrar.set('0002_deploy_Math_contract:operation-1:transaction-hash', '0x1234abcd')
registrar.set('0002_deploy_Math_contract:operation-1:contract-address', '0xabcd6789')

Then, future migrations could reference this value something like the following.

class Migration(migrations.Migration):
    ...
    operations = [
        migrations.SendTransaction({
            'from': '0x1234abcd',
            'to': migrations.RegistrarValue('0002_deploy_Math_contract:operation-1:contract-address`, type='address'),
        })
    ]

Then, within the execution of the SendTransaction operation, it would attempt to resolve the value associated with this key and use it as the to destination for this transaction.