| Age | Commit message (Collapse) | Author |
|---|
|
processes
Tables or data containers should be owned and monitored by mnesia_monitor and
should thus be created by that process.
Always create_table before loading it
We need to create tables for ram_copies at least before loading
them as they are intermittent. It is also needed to get mnesia
monitor as the parent and supervisor of the data storage.
|
|
Make ram_copies index always use ordered_set
And use index type as prefered type not a implementation requirement,
the standard implmentation will currently ignore the prefered type.
|
|
There is no need to update the index table if a record is updated in non
indexed field. This removes one timing glitch where dirty_index_read would
return an empty list for records that where updated.
There is still an issue with dirty_index_read when updates are made to
the index field, it have been reduced but the real table updates are made
after the index table references have been added.
Originally reported by Nick Marino in erl-questions mailing list, thanks.
|
|
|
|
Avoids building stacktraces where it is not needed and do
not mask errors, i.e. only catch the relevant classes in each try.
|
|
|
|
|
|
|
|
The previous commit contained a regression that would trigger a crash
when attempting to add an index to an Mnesia table of type ordered_set.
|
|
ETS bag tables have very poor performance on insertion if you have lots
of rows with duplicate keys, since it has to check each existing record
and make sure it's not inserting any duplicates. This can lead to some
pretty drastic slowdowns when inserting lots of rows into an Mnesia
table, IF you're introducing lots of duplicate values into an indexed
column.
As it turns out, we can fix this by switching to duplicate_bag tables
for storing Mnesia indexes on tables of type 'set', and it ultimately
makes no functional difference since we will never actually attempt to
insert any duplicate records anyway. (We would have to make some bigger
changes to make this work for Mnesia bag tables though, so that is left
as a possible enhancement for the future.)
|
|
|
|
We have to ensure that we actually delete the last object with a
given (key, index) pair before removing the index.
|
|
With help from Kostis
|
|
|
