increment() creates new keys.

[gf]

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

[Ian Holsman]

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

but if you do that the code around incrementing it would look quite
fugly no?

cnt = redis.INCR("foo");
if ( cnt is boolean && cnt == false ) {
redis.SET("foo",1);
}

?
this also leads to the problem of thread races where multiple people are
executing the same logic. you might have n threads/clients running
through this code at the same time.
and you would end up with 'foo' being 1. instead of n.
so your logic would then need to be something like

redis.lock("foo")
cnt = redis.INCR("foo");
if ( cnt is boolean && cnt == false ) {
redis.SET("foo",1);
}
redis.unlock("foo")


> >
>
>

[gf]

Just SETNX ;-)

[Ian Holsman]

gf wrote:
> Just SETNX ;-)
>
>

similar issues.
you end up with this.

if (!redis.INCR(foo) {
if ( !redis.SETNX(foo,1) ) {
redis.INCR(foo)
}
}
as 2 people could be incrementing the counter (and failing) at the same
time, and trying to set it to 1 at the same time (with 1 failing).
fugly.

[gf pro]

while (!redis.INCR(foo)) {redis.SETNX(foo,1);}

2009/7/17 Ian Holsman <kry...@gmail.com>

[Salvatore Sanfilippo]

On Thu, Jul 9, 2009 at 8:01 PM, gf<kak.serpom...@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.

Cheers,
Salvatore

> >
>



--
Salvatore 'antirez' Sanfilippo
http://invece.org

"Once you have something that grows faster than education grows,
you’re always going to get a pop culture.", Alan Kay

[Chris Lamb]

Salvatore Sanfilippo wrote:

> This is the best thing we can do to make the Redis usage simpler and
> avoid race conditions.

Agree 100%, but you forgot the other advantage that it makes storing
empty lists and zero-value counters completely free.

Regards,

--
Chris Lamb, UK ch...@chris-lamb.co.uk
GPG: 0x634F9A20

[Salvatore Sanfilippo]

On Fri, Jul 17, 2009 at 11:01 AM, Chris Lamb<ch...@chris-lamb.co.uk> wrote:
> Salvatore Sanfilippo wrote:
>
>> This is the best thing we can do to make the Redis usage simpler and
>> avoid race conditions.
>
> Agree 100%, but you forgot the other advantage that it makes storing
> empty lists and zero-value counters completely free.

Indeed! This is a great point too.

Cheers,
Salvatore

>
>
> Regards,
>
> --
> Chris Lamb, UK                                     ch...@chris-lamb.co.uk
>                                                          GPG: 0x634F9A20
>

--

[gf]

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

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.
>
> Cheers,
> Salvatore
>
>
>
> --

> Salvatore 'antirez' Sanfilippohttp://invece.org

[Michel Martens]

On Tue, Jul 28, 2009 at 8:27 AM, gf<kak.serpom...@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

[Riccardo Marangone]

Michel,
at this time I have never used Redis DB (I don't know if redis can do
following things in another way), but I think that in some cases incr can be
used also as a semaphore, eg: first time do some system initializations and
(in case of multiple requests) only one process will do that.

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);

[Salvatore Sanfilippo]

On Thu, Jul 30, 2009 at 9:21 AM, Riccardo
Marangone<riccardo....@libero.it> wrote:

> used also as a semaphore, eg: first time do some system initializations and
> (in case of multiple requests) only one process will do that.

Hello, use RENAMENX in order to implement this pattern. It's just the same.

Cheers,
Salvatore

--
Salvatore 'antirez' Sanfilippo