Re: mnesia:match_object() on an ordered_set

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> 
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> 
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> 
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
penalty?

/Håkan

---
Håkan Mattsson
Ericsson
High Availability Software, DBMS Internals
http://www.ericsson.com/cslab/~hakan/