The conversion from WebSQL to Sqlite-WASM was anything but trivial, as the restrictions imposed by each module meant a simple translation layer was not possible. WebSQL is entirely asynschronous. WASM calls are synchronous, but the process is made asynch by forcing wasm to run in a worker. But workers cannot use callbacks to non-worker code, so we need a system of forward and return messages.

This documentation summarises the message passing process just for my benefit. It is very incomplete

The Results Tab handles message passing to and from the DB worker.

Main Page (DNA Relatives)

The Gather-529 button updates the DB with content of DNA matches.

The main content code attached to the relatives list is in scan_relatives.js

It apparently has to reload the entire list (1500) from the Ajax call as this js code cannot access the original download. The callback fill_relative_details() is made when download completed. This fills a relativesMap with data indexed by the UID, including data which has not been allowed for in the DB.

Gather-529

This button will store any useful data in DB

1. pass message "process_relatives" to results tab, with relatives data (It was a Map, but that cannot be passed across messages, so done as array)
2. forward same message to DBworker.
3. in worker.js, "process_relatives" message passes args to DBwasm.processRelatives()
4. in dbcode.js,

• inserts(ignore) profile if a new one is found
• inserts(ignore) idalias table with name and date of the profile person.
• for each relative,
  • inserts(ignore) alias table
  • inserts(ignore) DNArelatives table with side, notes
  • if DNArelatives entry already exists then side, notes are updated if they were previously emepty
  • insert(ignore) DNAmatches summary between profile and relative (pct chared, cM, n segs) returns a count of updates

Scan ICWs button

normal mode

• calls run_ICW_scan()

shift-click mode (force rescan)

Initially I was just going to set code to unconditionally rescan every relative. Then I realise that if anything went wrong then the only options were start again from the beginning or, more likely, user would not realise some fraction had not been rescanned and carry on.

So, it requires another flag in the DB for each specific relative in the current list to the profile person. And more complicated code...

• sends "force_ICW_rescan" message to resuls tab, thence to db-worker and DB code, which simply sets bit in DB.
• on return need to refresh _triangMap _ before rejoining main path.

run_ICW_scan() function

• for every DNA relative (in relativesMap)
  • check value in _triangMap _- these flags determine if need to scan this relative - add to queue of relatives to be scanned if so indicated
• do next_relative_scan(). This function prepares the icwQueue with content for the next relative. The queue includes content to construct the url for the required ajax calls:
  • ...//family_background/ - returns only a family tree url
  • haplogroup - only if DNA sharing is enabled, otherwise the request returns a 403
  • .../relatives_in_common/ - this retrieves data on all in-common relatives, rather than 10 at a time.
• call launch_next_icw_ajax_query() which processes each entry in the icwQueue in turn
  • the callbacks when each part of the ajax completes save data for processing later. Each of those functions calls launch_next_icw_ajax_query() to start the next step
• the final step leads to load_icw_list(), which prepares the icwMap, as objects indexed by the match's ID

This leads to fill_ICW_details(), which:

• saves any haplogroup to DB
• saved family tree url, if any
• passes the message "update_ICWs", along with the ICW array (which includes the pct shared and predicted relationship.)

DNA Match page

These pages have /profile/xxxx in the url, so they are sometimes referred to as profile pages, however the term "profile" is reserved in this code for the DNA testers that are managed by this account. These pages are for a relative who matches the specified profile person.

The main content code attached to the relative profile page is in save_segments.js (even though there are no segments atm)

Match page startup

When the page code is loaded and run, it extracts the profile and Match UID and name and then

• sends a "get_ICW_prelude" message to the results tab.
• this passes details to the DB worker with the same message code
• the worker calls DBwasm.getICWPrelude()
• DBwasm.getICWPrelude does the following using profileID and matchID
  • updates new profiles
  • get table of all in DNAmatch who match the profileID
  • get table of all in DNAmatch who match the matchID
  • get all entries in ICWsets between profile, match and 3rd person.
  • returns the 3 tables
• the worker then passes a message type "ICWPrelude_return" with the those tables from the DB lookup
• it send a message back to the originating page, read by the save_segments code. The message listener calls load_match_cache(payload)...

The load_match_cache() Function

Takes the returned tables/objects and loads the content into:

• profileMatchesMap, contains objects of profileMatch data indexed by the Relative's ID
• matchMatchesMap, contains objects of testers who are in common with with both the Profile person and the relative.data indexed by the Relative's ID, and
• sharedSegMapMap, contains objects of profileMatch data indexed by the Relative's ID

Triangulate into 529Renew

At this stage (2024) there are no new triangulations, so it is really just collecting ICW data.

The process is undertaken at tr_el.onclick= but is blocked at the moment due to no chromosome data.

• get extra data from match - this includes maternal and paternal haplogroups
  • update haplogroup info
• get the list of 10