mnesia:match_object() on an ordered_set
Thu Apr 24 18:17:07 CEST 2003
On Thu, 24 Apr 2003, Ulf Wiger wrote:
Uffe> I started writing some code happily assuming that calling
Uffe> mnesia:match_object/2 on an ordered_set table will return
Uffe> an ordered set of objects. For a brief moment, some doubt
Uffe> snuck in and I decided to check the actual implementation...
Uffe> It turns out, AFAICT, that mnesia simply prepends objects
Uffe> written during the transaction, thus breaking the
Uffe> ordered_set semantics, and -- In my opinion -- violating the
Uffe> Principle of Least Surprise(tm).
Uffe> The Mnesia documentation doesn't make any promises regarding
Uffe> order, so this behaviour doesn't formally violate the Mnesia
Uffe> interface. However, where anything is written about the
Uffe> expected semantics of match_object(), the following can be
Uffe> found in the ETS Reference Manual:
Uffe> "On tables of the ordered_set type, the result is in the
Uffe> same order as in a first/next traversal."
The Mnesia API does only support first/next traversal with dirty
semantics and for a match_object with dirty semantics there are no
transaction store to bother about. ;-)
Uffe> Given the current implementation of mnesia:match_object(), I
Uffe> don't think preserving the order would have to impact
Uffe> performance, esp. not on large sets (and on small sets, I
Uffe> don't think it matters.)
For fragmented tables it would have a tremendous impact, as the order
only is preserved within each fragment. In order to return an ordered
result, it would require a quite substantial sort operation.
Of course Mnesia could ensure that the result of a match_object on an
ordered_set always should be ordered, but is it worth the performance
High Availability Software, DBMS Internals
More information about the erlang-questions