I think it is really split on how people are using it. I agree that for some there is a increment
and forget until I run an infrequent analysis. While others increment and read the value very
often. While we do both our most frequent use is that of reading the value very often. If changes
are made to the API lets make sure both use cases are considered and not just the "increment and
forget."
~Jeff
On 6/20/2011 12:03 PM, Joey Echeverria wrote:
Ah, I didn't realize that increment returns the value. Yes, the
current behavior is required in that case. I was thinking of a use
case more like the one Ted described, where you're keeping metrics,
but don't read the values that frequently. Maybe this should be a new
API call.
If no one objects, I'll file a JIRA.
-Joey
On Mon, Jun 20, 2011 at 1:27 PM, Joe Pallas<joseph.pal...@oracle.com> wrote:
On Jun 20, 2011, at 8:50 AM, Ted Dunning wrote:
Lazy increment on read causes the read to be expensive. That might be a win
if the work load has lots of data that is never read.
This could be a good idea on average because my impression is that increment
is usually used for metric sorts of data which are often only read in detail
in diagnostic post mortem use cases.
Just so we're clear, we'd be talking about a new operation, right? Because
today's increment returns the incremented value, and some uses (like generating
unique values) do require that.
joe
--
Jeff Whiting
Qualtrics Senior Software Engineer
je...@qualtrics.com
