[
https://issues.apache.org/jira/browse/PHOENIX-5044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16702159#comment-16702159
]
Lars Hofhansl commented on PHOENIX-5044:
----------------------------------------
The cases where UPSERT/SELECT is possible serverside are actually limited:
* same table
* no global mutable indexes
* autocommit on
* no sequences used
* no row timestamps
* no aggregation, limit, subqueries, etc
So that pretty much leaves an UPSERT for existing rows (hard to make a new
unique key without a sequence).
I'll let this sit here for a bit. [[email protected]], [~elserj], any comments?
> Remove server side mutation code from Phoenix
> ---------------------------------------------
>
> Key: PHOENIX-5044
> URL: https://issues.apache.org/jira/browse/PHOENIX-5044
> Project: Phoenix
> Issue Type: Task
> Reporter: Lars Hofhansl
> Priority: Major
> Attachments: 5044-looksee-v2.txt, 5044-looksee.txt
>
>
> This is for *discussion*. Perhaps controversial.
> It generally seems to be a bad idea - if well-intentioned - idea to trigger
> mutations directly from the server. The main causes are UPSERT SELECT for the
> same table and DELETE FROM.
> IMHO, it's generally better to allow the client to handle this. There might
> be larger network overhead, but we get better chunking, better pacing, and
> behavior more in line with how HBase was intended to work.
> In PHOENIX-5026 I introduced a flag to disable server triggered mutations in
> the two cases mentioned above. I now think it's better to just remove the
> server code and also perform these from the client.
> (Note that server side reads - aggregation, filters, etc - are still insanely
> valuable and not affected by this)
> Let's discuss.
> [~tdsilva], [[email protected]], [~jamestaylor], [~vincentpoon], [~gjacoby]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
