Details
-
Bug
-
Status: Resolved
-
Minor
-
Resolution: Won't Fix
-
1.4, 1.4.1
-
None
-
None
Description
1. Not sure it's a bug, but looks like a bug to me - if the query returns any values other than $deleteDocById for the row you want deleted, it deletes the row but also re-adds it with the rest of the data, so in effect the row isn't deleted. In order to work around this issue, you have to either make sure no data other than $deleteDocById=<id> exists in rows to be deleted or add $skipDoc='true'
(which I think is a little counter-intuitive, but was the better choice in my case). My query looks something like:
SELECT u.id,
u.name,
...
IF(u.delete_flag > 0, u.id, NULL) AS $deleteDocById,
IF(u.delete_flag > 0, 'true', NULL) AS $skipDoc FROM users_tb u
2. $deleteDocById doesn't update the statistics of deleted documents.
This has 2 downsides, the obvious one is that you don't know if/how many documents were deleted, the not-so-obvious one is that if your import contains only deleted items, it won't be committed automatically by DIH and you'll have to commit it manually.
Attachments
Issue Links
- is duplicated by
-
SOLR-2492 DIH does not commit if only Deletes are processed
- Closed