[Fwd: rdbms-1.0 user contribution]

Ulf Wiger ulf.wiger@REDACTED
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
> release.

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     <ulf.wiger@REDACTED>
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 mailing list