Confirmed users
574
edits
DXR Storages: Difference between revisions
Jump to navigation
Jump to search
Added some thoughts on keeping deployment synchronized to the proper version of outboard indices.
(Added some thoughts on keeping deployment synchronized to the proper version of outboard indices.) |
|||
| Line 43: | Line 43: | ||
* Ability to cap memory use for regex searches. Currently set at 8MB. | * Ability to cap memory use for regex searches. Currently set at 8MB. | ||
* Guaranteed linear-time searching (with relation to the corpus size), because it makes automatons rather than doing backtracking—nice for fending off DOSes. [Actually, I'm not sure ES or PG don't do that as well. The Lucene RegexpQuery is a subclass of AutomaticQuery.] | * Guaranteed linear-time searching (with relation to the corpus size), because it makes automatons rather than doing backtracking—nice for fending off DOSes. [Actually, I'm not sure ES or PG don't do that as well. The Lucene RegexpQuery is a subclass of AutomaticQuery.] | ||
== Keeping Outboard Storages Synced == | |||
Deployment is easy right now because static HTML files and the SQLite DB are all in the same folder. We do an atomic move of the whole thing into place, and that's our deploy process. For a data store off on a different machine someplace, this gets slightly more (though not too) interesting. We can dump a random identifier into config.py in the instance and make that identifier part of the ES (or whatever) index we build as part of that instance-build. Just make sure the deploy script deletes the old index after it pushes the instance using the new one into production. | |||