path fields - bootstrap broken in 8.0-7 #850
Comments
|
Folks, i have already created a fix for this locally and am happy to submit this in a PR. If so please let me know how you want it.. (i assume create a new branch off master and create the PR from that).. just in case you have any specific procedures.. just let me know |
|
Hi @joecrean. We've got a CONTRIBUTING.md file that shows how to submit a PR for this project. Part of it is using a feature branch off the dev branch, rather than master. Your PR would be welcome. |
Since the upgrade to MarkLogic 8.0-7 roxy bootstrap fails in an environment where the application was already deployed (and by converse it does not fail in a fresh environment). Path namespaces are removed and then added every time bootstrap runs. In order to remove them we first need to check if they are being used. They can be used in Path Range Index definitions, elements containing Geospatial co-ordinates and Field definitions. The API used to delete the path namespaces is called admin:database-delete-path-namespace. This API will check to see if the namespaces are in use before deletion and in 8.0-7 this has been tightened up to additionally check field definitions. Up to now roxy has simply deleted and re-added ALL path range indexes and their namespaces which in itself could cause lots of re-indexing. Now with the stricter API we would need to delete and re-add field range indexes. This is clearly a bad direction and for that reason this solution, detects what has changed and only removes indexes when it is really necessary.
|
created pull request for this |
Since the upgrade to MarkLogic 8.0-7 roxy bootstrap fails in an environment where the application was already deployed (and by converse it does not fail in a fresh environment). Path namespaces are removed and then added every time bootstrap runs. In order to remove them we first need to check if they are being used. They can be used in Path Range Index definitions, elements containing Geospatial co-ordinates and Field definitions. The API used to delete the path namespaces is called admin:database-delete-path-namespace. This API will check to see if the namespaces are in use before deletion and in 8.0-7 this has been tightened up to additionally check field definitions. Up to now roxy has simply deleted and re-added ALL path range indexes and their namespaces which in itself could cause lots of re-indexing. Now with the stricter API we would need to delete and re-add field range indexes. This is clearly a bad direction and for that reason this solution, detects what has changed and only removes indexes when it is really necessary.
|
If possible, we could really use this fix. We've been waiting for it to get merged in before deploying it. |
|
Did this fix actually get merged in? |
|
Unfortunately not, let me see if I can finish reviewing this. I need to take a close look at the changes.. |
…arklogic-community#863: metadata fields, geo path indexes, and path namespaces fix
|
Fixed in dev |
Bug Template
Short description of the problem:
Since the upgrade to MarkLogic 8.0-7 roxy bootstrap fails in an environment where the application was already deployed (and by converse it does not fail in a fresh environment).
Path namespaces are removed and then added every time bootstrap runs. In order to remove them we first need to check if they are being used. They can be used in Path Range Index definitions, elements containing Geospatial co-ordinates and Field definitions. The API used to delete the path namespaces is called admin:database-delete-path-namespace. This API will check to see if the namespaces are in use before deletion and in 8.0-7 this has been tightened up to additionally check field definitions. If there are field definitions present with paths the deletion will fail with the exception ADMIN-PATHNAMESPACEINUSE.
What are the steps to reproduce the problem?
Tech Specs
Which Operating System are you using? CentOS 7
Which version of MarkLogic are you using? 8.0-7
Which version of Roxy are you using (see version.txt)? 1.7.6
The text was updated successfully, but these errors were encountered: