Bug #2747
Feature #2560: Enable link update of a "link updated" book
Duplicate left nodes present in the metagraph after doing link update for the book which was already link updated
Added by Venmuhilan B almost 2 years ago. Updated over 1 year ago.
100%
Updated by Venmuhilan B almost 2 years ago
- Subject changed from duplicate left nodes present in the metagraph after doing link update for the book which was already link updated to Duplicate left nodes present in the metagraph after doing link update for the book which was already link updated
Updated by Venmuhilan B almost 2 years ago
Issue:
The documentProcessingId of Langref present in some of the left nodes of metagraph of Libref is not as same as it is present in the documentProcessing kind.
documentProcessingId of Language Reference present in documentProcessing kind - efbad6c8-ef65-4d4d-bbd9-8c40e4ff683d
documentProcessingId of Library Reference present in documentProcessing kind - 63cc539d-a2b0-4e8b-af6c-4af095b59a1c
documentProcessingId of Language reference present in some of the left nodes of metagraph of Libref(which is not present in documentProcessing kind)- 96ac5352-3472-42c9-b48f-8bca6e874d93.
In the method expandUrlsForNodes(), the lurl will not be set to the node because it will not get the baseUrl for this dpID 96ac5352-3472-42c9-b48f-8bca6e874d93(which is not present in the documentProcessing kind).So, the Url(i.e 10004/compound_stmts--The-try-statement-158.html) will not be expanded to lurl. I think it won't find the document from getDocumentByDocumentUrlAndSupplementAsNull() because the l-url is invalid and that method will return null. When it tries to get the indexName, a null pointer exception occurred.
The line where the exception occurred:
indexName = contentDao.getDocumentByDocumentUrlAndSupplementAsNull(node.getUrl(),null).getIndexName();
reason:
Library reference non-dt and Langauage reference non-dt were ingested and link updated on 30 Aug on QA.
Langauage reference non-dt were deleted and reingested again on 21st sep.
So, The metagraph of Librref non-dt has the documentProcessingId of old Langref. It doesn't have the documentProcessingId of new Langref.
Fix & new issue.
If we overwrite with the same book or link update the book, we will not have this issue. But in the current implementation, it is not updating the nodes in metagraph which has the old book's dpId with the new book's dpId. Instead it created duplicate nodes with the new book's dpId. we have to fix this.
new issue:
I did the link update on Librref non-dt book to update the metagraph.
Instead of updating the dpId(i.e present as bookId) of the nodes, it created a two nodes which has documentProcessingId of new Langref book .
i.e
"left": [
.
.
.
.
{
"rc": 15,
"id": 131234,
"title": "The try statement,try",
"label": "8.4. The try \nstatement",
"url": "10004/compound_stmts--The-try-statement-158.html",
"rank": 168,
"bookId": "96ac5352-3472-42c9-b48f-8bca6e874d93"
},
{
"rc": 15,
"id": 131235,
"title": "The try statement,try",
"label": "8.4. The try \nstatement",
"url": "10004/compound_stmts--The-try-statement-158.html",
"rank": 168,
"bookId": "96ac5352-3472-42c9-b48f-8bca6e874d93"
},
{
"rc": 15,
"id": 131234,
"title": "The try statement,try",
"label": "8.4. The try \nstatement",
"url": "10004/compound_stmts--The-try-statement-158.html",
"rank": 170,
"bookId": "efbad6c8-ef65-4d4d-bbd9-8c40e4ff683d"
},
{
"rc": 15,
"id": 131235,
"title": "The try statement,try",
"label": "8.4. The try \nstatement",
"url": "10004/compound_stmts--The-try-statement-158.html",
"rank": 170,
"bookId": "efbad6c8-ef65-4d4d-bbd9-8c40e4ff683d"
}
]
Updated by Venmuhilan B almost 2 years ago
Fixed in this MR - https://gitlab.com/kordale/rapidken-j/-/merge_requests/1573
Updated by Venmuhilan B almost 2 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
Updated by Ayush Khandelwal over 1 year ago
- Status changed from Feedback to Closed
working as expected