Get chainquery merged and live into production. #71

New issue

Closed

opened 2018-05-13 01:05:21 +02:00 by filipnyquist · 2 comments

filipnyquist commented

2018-05-13 01:05:21 +02:00

(Migrated from github.com)

@tiger5226 is working on integrating chainquery into lighthouse. When my review is done the next step is deployment to a live server, this means starting over with a new elasticsearch database.

My main idea was to redeploy ligthhouse to a new server, get it synced up and then change the DNS for lighthouse.lbry.io to the new one. Then let the DNS change propagate and remove the old server.

Feel free to add your ideas down below!

@tiger5226 is working on integrating chainquery into lighthouse. When my review is done the next step is deployment to a live server, this means starting over with a new elasticsearch database. My main idea was to redeploy ligthhouse to a new server, get it synced up and then change the DNS for lighthouse.lbry.io to the new one. Then let the DNS change propagate and remove the old server. Feel free to add your ideas down below!

tiger5226 commented

2018-05-13 01:46:07 +02:00

(Migrated from github.com)

We now have the https://github.com/lbryio/lighthouse/tree/chainquery branch and a PR for code review #72.

The basic idea for a phase 1 is replace the current sync process with one that leverages chainquery instead of a direct connection to lbrycrd. This allows us to avoid rewriting the same code for all of our applications. The requirement is that it should not change the search results in any significant way. This change should be seamless. Future changes can then leverage the additional information chainquery can provide, enhancing our search and discovery with very little effort.

This change just modifies where information is synced from and refactors how it syncs.

It will now query chainquery for all updated claims since the last time it synced. This will allow for updated claims to actually be updated in the elastic search db. Previously this was not possible as a diff was used. It does this via a new persistent json file that stores this information and can be used for further minor state changes.

The changes are in the chainquery directory and the intention is that we will eventually just replace the importer directory with what is in chainquery.

We now have the https://github.com/lbryio/lighthouse/tree/chainquery branch and a PR for code review #72. The basic idea for a phase 1 is replace the current sync process with one that leverages chainquery instead of a direct connection to lbrycrd. This allows us to avoid rewriting the same code for all of our applications. The requirement is that it should not change the search results in any significant way. This change should be seamless. Future changes can then leverage the additional information chainquery can provide, enhancing our search and discovery with very little effort. This change just modifies where information is synced from and refactors how it syncs. It will now query chainquery for all updated claims since the last time it synced. This will allow for updated claims to actually be updated in the elastic search db. Previously this was not possible as a diff was used. It does this via a new persistent json file that stores this information and can be used for further minor state changes. The changes are in the `chainquery` directory and the intention is that we will eventually just replace the importer directory with what is in `chainquery`.

tiger5226 commented

2018-05-17 23:50:22 +02:00

(Migrated from github.com)

Deployed