mnesia_frag_hash(3)

💖 mnesia_frag_hash — the vibe check 💖

okay so bestie, we're in the Erlang Module Definition section of the mnesia manual, and today's main character is mnesia_frag_hash(3). she's a behavior. she's a callback contract. she's giving "I define the rules, you implement the drama." 🎀

---

✨ NAME ✨

mnesia_frag_hash — Defines mnesia_frag_hash callback behavior 🦋

---

🌸 DESCRIPTION 🌸

This module defines a callback behavior for user-defined hash functions of fragmented tables. no cap, that's the whole job description and she eats every time.

Which module gets picked to implement the mnesia_frag_hash behavior for a particular fragmented table? You specify that alongside the other frag_properties. The hash_module is the one that defines the module name. And the hash_state defines the initial hash state. two little properties, huge responsibilities 💅

This module implements dynamic hashing, which is a kind of hashing that grows nicely when new fragments are added. it's well suited for scalable hash tables — literally built different, she scales, she expands, she never has a bad fragment day. 🔥

👀 See Also

• mnesia

---

⭐ FUNCTIONS ⭐

🧚 add_frag(State :: term()) -> {NewState, IterFrags, AdditionalLockFrags} when NewState :: term(), IterFrags :: [integer()], AdditionalLockFrags :: [integer()].

To scale well, it is a good idea to ensure that the records are evenly distributed over all fragments, including the new one. spread them out bestie, no clumping, no one fragment carrying the whole group project 🙈

NewState is stored as hash_state among the other frag_properties.

As a part of the add_frag procedure, Mnesia iterates over all fragments corresponding to the IterFrags numbers and starts key_to_frag_number(NewState,RecordKey) for each record. If the new fragment differs from the old fragment, the record is moved to the new fragment. like a glow-up relocation, we love to see it 💖

As the add_frag procedure is a part of a schema transaction, Mnesia acquires write locks on the affected tables. That is, both the fragments corresponding to IterFrags and those corresponding to AdditionalLockFrags. locks are on, so play nice. 🔒

---

🦋 del_frag(State :: term()) -> {NewState, IterFrags, AdditionalLockFrags} when NewState :: term(), IterFrags :: [integer()], AdditionalLockFrags :: [integer()].

NewState is stored as hash_state among the other frag_properties. same energy as before, different function name 🎀

As a part of the del_frag procedure, Mnesia iterates over all fragments corresponding to the IterFrags numbers and starts key_to_frag_number(NewState,RecordKey) for each record. If the new fragment differs from the old fragment, the record is moved to the new fragment. she's migrating records, respectfully ✨

Notice that all records in the last fragment must be moved to another fragment, as the entire fragment is deleted. not optional bestie, the whole fragment is leaving the group chat and she is NOT taking the records with her 💀

As the del_frag procedure is a part of a schema transaction, Mnesia acquires write locks on the affected tables. That is, both the fragments corresponding to IterFrags and those corresponding to AdditionalLockFrags. yes, the same locking situation as add_frag, we're consistent like that. 🔐

---

🌈 init_state(Tab, State) -> NewState when Tab :: atom(), State :: term(), NewState :: term().

Starts when a fragmented table is created with the function mnesia:create_table/2, or when a normal (unfragmented) table is converted to be a fragmented table with mnesia:change_table_frag/2. so she's the origin story, the pilot episode, the first day of school 🍓

Notice that the function add_frag/2 is started one time for each of the other fragments (except number 1) as a part of the table creation procedure. fragment number 1, you're special, you sat this one out.

State is the initial value of the hash_state frag_property. NewState is stored as hash_state among the other frag_properties. handing off the baton with style 💅

---

💜 key_to_frag_number(State, Key) -> Fragnum when State :: term(), Key :: term(), Fragnum :: integer().

Starts whenever Mnesia needs to determine which fragment a certain record belongs to. It is typically started at read, write, and delete. so pretty much all the time — she's booked and busy, main character energy fr fr 👑

---

🎀 match_spec_to_frag_numbers(State, MatchSpec) -> Fragnums when State :: term(), MatchSpec :: ets:match_spec(), Fragnums :: [integer()].

This function is called whenever Mnesia needs to determine which fragments that need to be searched for a MatchSpec. It is typically called by select and match_object. she's the one who knows exactly which fragments to go knock on, no wasted trips, iconic behavior ⭐

---

and that's the whole page diva 💖 every callback, every lock, every frag_properties mention — nothing skipped, nothing invented, just vibes plus accuracy.

with love from Ericsson AB, and straight outta mnesia 4.26.2, this was mnesia_frag_hash(3) — mwah, slay, byeee 🫶🌸