[Fwd: rdbms-1.0 user contribution]
Thu Jan 14 10:42:09 CET 1999
Hakan Mattsson wrote:
> My intention is not to make the internal functions hard to use. But
> writing documentation of these have had a rather low priority. The
> main reason for not encouraging usage of internal functions is that
> their behaviour may be changed without any notice. We put no effort in
> making them backwards compatible. You have to be aware about that if
> your code uses internal functions, it may be broken in the next
Indeed! It's happened to me a couple of times.
That's life on the bleeding edge. (:
I use the following undocumented mnesia functions in rdbms:
- I fetch the transaction data directly from the process dictionary
(could have used mnesia:get_activity_id(), but I didn't see it,
and it's also marked as "not for public use" btw)
I decided to do this since the dictionary generates read/write
activity inside the transaction; if it would use
mnesia:read/1 and mnesia:write/1, it would create a loop (they are
forwarded back again to the dictionary for verification.)
It would have been possible to work around it, but this felt like
the most elegant solution.
- mnesia_schema:schema_transaction/1 and
This could perhaps have been avoided if I'd realised that there
was a 'user_properties' option for create_table/2.
If I figure out a way to rewrite this cleanly to use only the official
API, I will of course do that.
BTW, I would like to be able to specify commit() and rollback() hooks in
the access module as well. I can imagine that such hooks would be
dangerous, but it would allow me to write safe triggers inside the
transaction. Currently, I have to wait until after commit/rollback and
do a post_update trigger - not atomic.
Ulf Wiger, Chief Designer AXD 301 <>
Ericsson Telecom AB tfn: +46 8 719 81 95
Varuvägen 9, Älvsjö mob: +46 70 519 81 95
S-126 25 Stockholm, Sweden fax: +46 8 719 43 44
More information about the erlang-questions