Tue Mar 6 10:31:17 CET 2007
> It definitely seems like a bug, but I think that's intended behavior
> for backwards compatibility.
I'm not sure it was intended in the past, coz the returned value for use by the function caller is 1 while the stored value for future increment is 0, which means the next returned value will still be
1, not being incremented the second time (and so generating overriding updates in mnesia records in my case...)
If it was intended, the doc should at least be updated to describe this behaviour.
Right now, my own workaround is just to be sure to correctly initialize the counter table with some value (0 is ok) before calling dirty_update_counter for the first time.
> Here's what we do, which seems to work:
> case mnesia:dirty_update_counter(Db, Key, Inc) of
> X when X == Inc ->
> F = fun () ->
> [R] = mnesia:read(Db, Key, write),
> _ ->
> On 3/5/07, Sébastien Saint-Sevin <seb-cl-mailist@REDACTED> wrote:
>> Hi list,
>> It seems I've found a bug regarding mnesia:dirty_update_counter(Tab,
>> Key, Incr).
>> When I use the function for the first time with an Incr of 1 (Key not
>> existing), the table is populated with a value of 0 for the key Key (1
>> expected) and returns 1 for NewVal (as expected).
>> The doc says : "If Key don't exits, a new record is created with the
>> value Incr if it is larger than 0, otherwise it is set to 0."
>> Is this confirmed or did I missed something ?
>> PS : erl-5.5.3 under windows XP
>> erlang-questions mailing list
More information about the erlang-questions