LRS Migration Documentation

[amerryma]

Hi there, I'm looking into migrating state and statements data from an existing LRS into lrsql. Are there any documents, tools, or APIs available to support this kind of migration?

A few approaches I’m considering:

Direct DB migration: Export data and transform it into SQL insert statements for all the relevant tables.

API-based migration: If lrsql exposes an admin-level API for backfilling statements and state, this would be ideal. It would abstract away internal table structure and help ensure data consistency.

One key requirement: I need to preserve the original stored timestamps from the source system. That’s currently my biggest blocker in evaluating the right path forward.

Any suggestions or guidance would be appreciated!

[milt]

Hi @amerryma! Thanks for checking out SQL LRS. Please see my responses inline:

Direct DB migration: Export data and transform it into SQL insert statements for all the relevant tables.

This route would likely be difficult as the LRS performs extensive denormalization of statements and you'd have to match this for the LRS to function correctly. That said, our LRS is completely open source and you are welcome to use any code in the repository to write your own migration scripts!

API-based migration: If lrsql exposes an admin-level API for backfilling statements and state, this would be ideal. It would abstract away internal table structure and help ensure data consistency.

One key requirement: I need to preserve the original stored timestamps from the source system. That’s currently my biggest blocker in evaluating the right path forward.

I agree that API-based migration is ideal (we wrote an application to do it), but the stored stamp requirement is a tough one. Our LRS follows the spec which says this value MUST be overwritten. Also internally there are implementation details that make changing the stored time problematic.

If we came across this requirement in the wild we'd probably define a context extension to preserve the old stored stamp at migration-time, but that may or may not fit your use case.

[amerryma]

So maybe, I could use the API based migration, then go back and just retouch the stored timestamps with a SQL script?

If we came across this requirement in the wild we'd probably define a context extension to preserve the old stored stamp at migration-time, but that may or may not fit your use case.

I will think more on this too.