migrations

[joe-getcouragenow]

v2 looks awesome.

Really like the DSL and aggregations.

One thing that is blocking is Migrations. Does anyone have any thoughts on a strategy for this ?

[timshannon]

You can just get every key from the old DB and put them into the new one. Everything badgerhold uses (indexes, type info, etc), is stored in the database.

[IvanTurgenev]

You can just get every key from the old DB and put them into the new one. Everything badgerhold uses (indexes, type info, etc), is stored in the database.

to create backups?

[gedw99]

No to migrate the data from one Schema to another.

For small dbs it’s ok but for large ones it’s going to present time and disk space issues.

i guess you could also write a migration to change the shape of the dara within the same dB. Just iterate the type and replace it with a new structure.
Would need to back it up first anyway I suspect in case the power fails half way through etc

[timshannon]

Changing the shape of the structure ( adding or removing fields) will entirely depend on the encoding type used and how that encoding type will handle the change.

…

On Sat, Mar 13, 2021 at 1:29 PM ged ***@***.***> wrote: No to migrate the data from one Schema to another. For small dbs it’s ok but for large ones it’s going to present time and disk space issues. i guess you could also write a migration to change the shape of the dara within the same dB. Just iterate the type and replace it with a new structure. Would need to back it up first anyway I suspect in case the power fails half way through etc — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#44 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKE2NL3JGF5S3RPJ7RD323TDO4LHANCNFSM4TEYGARA> .

-- Tim Shannon www.townsourced.com