> if (incr(x) === false) {
>    // may be first time increment

>    if( add(x,1)!==false) {
>        // is the first time and I'm "first action" owner
>        update_user_info("some user's info profile to update");
>        activate_process_onto_subsystem_x();
>        ...

>    } else {
>        // another process has initialized counter
>        incr(x);

>    }
> }

> ----- Original Message -----
> From: "Michel Martens" <sove...@gmail.com>
> To: <redis-db@googlegroups.com>
> Sent: Tuesday, July 28, 2009 2:17 PM
> Subject: Re: increment() creates new keys.

> On Tue, Jul 28, 2009 at 8:27 AM, gf<kak.serpom.po.yait...@gmail.com> wrote:
>> On 17 июл, 12:50, Salvatore Sanfilippo <anti...@gmail.com> wrote:
>>> On Thu, Jul 9, 2009 at 8:01 PM, gf<kak.serpom.po.yait...@gmail.com>
>>> wrote:

>>> > Hello.
>>> > "INCR notexists" returns 1, but I think it has to return "false".

>>> The whole Redis semantic, in order to be comfortable for the
>>> programmer, should try *hard* to avoid for patterns like:

>>> if .... the key exists ...
>>> do this
>>> else
>>> do that
>>> end

>>> or similar stuff. The whole Redis semantic follow this rule. SUNION
>>> nokey nokey2 will return an empty set for example, like LLEN
>>> foobared-no-key will return 0. This is the best thing we can do to
>>> make the Redis usage simpler and avoid race conditions.

>> I can not migrate from memcached. These patterns are needed really.
>> Do you want to add INCRX/INCRXBY/DECRX/DECRXBY?

> What's the example use case for this? Do you have any piece of code
> you can share with us?
> I like how Redis behaves now, makes a lot of sense to me, so I'd like
> to see exactly what's
> the case that is causing you problems.

> Regards,

> --
> Michel