Phoenix returns the number of delete markers that were placed if it’s a
point delete, not the actual number of rows deleted. Otherwise you’d need
to do a read before the delete (which would be costly). It’s possible that
this could be made configurable - please file a JIRA. You could work around
this by adding a nullable column that’s never populated to your primary key
or by adding another ANDed expression to your WHERE clause for a non pk
column which you know is always true.
On Thu, Feb 22, 2018 at 4:05 PM Sergey Soldatov <sergeysolda...@gmail.com>
> Hi Jins,
> If you provide steps to reproduce it would be much easier to understand
> where the problem is. If nothing was deleted the report should be 'No
> rows affected'.
> On Mon, Feb 19, 2018 at 4:30 PM, Jins George <jins.geo...@aeris.net>
>> I am facing an issue in which the number of rows affected by a DELETE
>> query returns an incorrect value. The record I am trying to delete does
>> not exists in the table, as evident from the first query but on deletion,
>> it reports 1 row is affected. Is this a known issue?
>> I have tried this in Phoenix 4.7 & Phoenix 4.13 and both behaves the same
>> 0: jdbc:phoenix:localhost> select accountId, subid from test.mytable
>> where accountid = '1' and subid = '1';
>> | ACCOUNTID | SUBID |
>> *No rows selected (0.017 seconds)*
>> 0: jdbc:phoenix:localhost> delete from test.mytable where accountid = '1'
>> and subid = '1';
>> *1 row affected (0.005 seconds)*
>> 0: jdbc:phoenix:localhost>
>> Jins George