Mnesia odd behaviour - delete_object

[Fredrik Linder]

Hi

In my eyes this looks like a bug in the transaction optimization algorithm.

Since the first WRITE operation conceptually is a DELETE + WRITE operation
(deleting the original value, and inserting the new value) it cannot
entirely be cancelled by the last DELETE operation (deleting the new value).

If this is the case, than I guess it is a bug in mnesia.

/Fredrik

----- Original Message -----
From: "Dan Gudmundsson" <dgud@REDACTED>
To: "Martin Bjorklund" <mbj@REDACTED>
Cc: <erlang-questions@REDACTED>
Sent: Tuesday, October 30, 2001 5:13 PM
Subject: Mnesia odd behaviour - delete_object


>
> Hi
>
> A explanation of the implementation, then you can argument about
> semantics :-)
>
> mnesia:delete_object({a, key, [1]}) deletes the object if
> and only if exactly that object exists in the database.
>
> So a mnesia:transaction(fun() -> mnesia:delete_object({a, key, [1]}) end)
> will not delete the object {a, key, [1,2]} since they are not the same.
>
> And since transactions doesn't directly operate on the tables, (not
> until the transaction commits), this happens.
>
> Thus when you over write the {a, key, [1]} in your transaction,
> you transaction view shows you the only record in the {a, key, [1]},
> and you delete that. This DELETES the WRITE operation you just did.
> And when the transaction commits, it tries to delete exactly the object
> {a, key, [1]} from table, which doesn't exist and you are left with
> you old value.
>
> Why this doesn't occur in the async_dirty and sync_dirty cases is
> obvious they don't have the transaction view, writes/deletes are done
> directly on the table.
>
> Hmm.. I need to sleep on this :-)
>
> /Dan
>
> Martin Bjorklund writes:
>  > I've got a funny mnesia situation.  The problem is delete_object
>  > vs. delete.
>  >
>  > I've got a simple 'set' table a:
>  >
>  >   mnesia:create_table(a, []).
>  >
>  > Add an object:
>  >
>  >   mnesia:dirty_write({a, key, [1,2]}).
>  >
>  > Now, I've got this fun:
>  >
>  >    F1 = fun() ->
>  >             mnesia:write({a, key, [1]}),  % modify the one&only object
>  >             [X] = mnesia:read({a, key}),  % read it
>  >             mnesia:delete_object(X)       % delete the one&only object
>  >         end.
>  >
>  > After executing F1 within a transaction, my table still contains the
>  > original object.  Since 'a' is a set, I'd think that the object would
>  > be removed.
>  >
>  > After executing F1 'async_dirty', the object is removed.
>  >
>  >
>  >    F2 = fun() ->
>  >             mnesia:write({a, key, [1]}),  % modify the one&only object
>  >             mnesia:delete({a, key})       % delete the one&only object
>  >         end.
>  >
>  > After executing F2 within a transaction, the object is removed.
>  >
>  >
>  > Can someone explain this behaviour??
>  >
>  >
>  > I've tested on mnesia 3.9.2 and 4.0.  It's probably not a bug, but I
>  > cannot come up with a interpretation that feels consistent...
>  >
>  >
>  >
>  > /martin
>
> --
> Dan Gudmundsson               Project:    Mnesia, Erlang/OTP
> Ericsson Utvecklings AB       Phone:      +46  8 727 5762
> UAB/F/P                       Mobile:     +46 70 519 9469
> S-125 25 Stockholm            Visit addr: Armborstv 1
>
>