boss_db:incr()

59 views
Skip to first unread message

Ken Rose

unread,
Jul 17, 2014, 12:52:59 AM7/17/14
to chica...@googlegroups.com
Anybody else having trouble with counters?  What am I doing wrong?

> boss_db:incr("foo").
** exception exit: {{{case_clause,{ok,0}},
                     [{boss_db_adapter_pgsql,incr,3,
                          [{file,"src/db_adapters/boss_db_adapter_pgsql.erl"},
                           {line,92}]},
                      {boss_db_controller,handle_call,3,
                          [{file,"src/boss_db_controller.erl"},{line,150}]},
                      {gen_server,handle_msg,5,
                          [{file,"gen_server.erl"},{line,580}]},
                      {proc_lib,init_p_do_apply,3,
                          [{file,"proc_lib.erl"},{line,239}]}]},
                    {gen_server,call,[<0.343.0>,{incr,"foo",1},30000]}}
     in function  gen_server:call/3 (gen_server.erl, line 190)
     in call from boss_pool:call/3 (src/boss_pool.erl, line 12)


Postgres has this:

# \d counters
           Table "public.counters"
 Column |          Type          | Modifiers
--------+------------------------+-----------
 name   | character varying(255) | not null
 value  | integer                | default 0
Indexes:
    "counters_pkey" PRIMARY KEY, btree (name)

Thanks,

 - ken

Ken Rose

unread,
Jul 17, 2014, 11:00:53 AM7/17/14
to chica...@googlegroups.com
I should have added that this is with CB 0.8.12 and Erlang 17.

- ken

Ken Rose

unread,
Jul 27, 2014, 12:29:29 AM7/27/14
to chica...@googlegroups.com

OK, the problem is that the Postgres adapter returns {ok,0} from the update attempt, instead of the expected {ok, _, _, [0]}.  It's not clear to me whether the adapter should be changed, or if the change should happen in boss_db:incr().  For now, I've implemented a local function to do the job.

incr(Name) ->
    Res = boss_db:execute("UPDATE counters SET value = value + 1 WHERE name = $1 RETURNING value;", [Name]),
    case Res of
    {ok, 0} ->
            Res1 = boss_db:execute("INSERT INTO counters (name, value) VALUES ($1, 1) RETURNING value;",
                [Name]),
            case Res1 of
                {ok, _, _, [{Value}]} -> Value;
                {error, Reason} -> {error, Reason}
            end;
        {ok, Value} -> Value;
    {ok, _, _, [{Value}]} -> Value
    end.

I'd be happy to do a patch for boss_db:incr, if that's the right way.  I'm less sure about the Postgres adapter.

 - ken

David Welton

unread,
Jul 28, 2014, 7:49:52 AM7/28/14
to chica...@googlegroups.com
> OK, the problem is that the Postgres adapter returns {ok,0} from the update
> attempt, instead of the expected {ok, _, _, [0]}. It's not clear to me
> whether the adapter should be changed, or if the change should happen in
> boss_db:incr(). For now, I've implemented a local function to do the job.

I think the adapter is the problem. It should handle {ok, 0}.

It'd be cool to add a test for this too...

--
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/

David Welton

unread,
Aug 25, 2014, 10:45:34 AM8/25/14
to chica...@googlegroups.com
On Mon, Jul 28, 2014 at 1:49 PM, David Welton <davidn...@gmail.com> wrote:
>> OK, the problem is that the Postgres adapter returns {ok,0} from the update
>> attempt, instead of the expected {ok, _, _, [0]}. It's not clear to me
>> whether the adapter should be changed, or if the change should happen in
>> boss_db:incr(). For now, I've implemented a local function to do the job.
>
> I think the adapter is the problem. It should handle {ok, 0}.

https://github.com/davidw/boss_db/commit/98646d61de64a00a6a740509de4c8961b3b73dfb

I don't think the {error} clause made much sense, and so I just kept
the two ok clauses, which seems to fix things.
Reply all
Reply to author
Forward
0 new messages