Packages

•  package root

  Definition Classes

  root

•  package org

  Definition Classes

  root

•  package sh

  Definition Classes

  org

•  package db

  Definition Classes

  sh

•  object MergedIndex

  purpose of this code:

  purpose of this code:

  Sometimes we have two tables (say INR withdraws and BTC withdraws) as below

  Table INR withdraws Table BTC withdraws ------------------------------------------- --------------------------------------------

  | time | withdrawID | Amount | userID | ... | time | withdrawID | Amount | userID | ...

  |------|------------|--------|--------|---- -------|------------|-----------------------

  | 23 | wjdejduejd | 34544 | alice | ... | 20 | ecjerjcruc | 146 | alice | ...

  | 45 | gtfcnmecnv | 4434 | bob | ... | 29 | roijfoirjf | 444 | carol | ...

  | 54 | 4jto4rkmkc | 3444 | alice | ... | 34 | i4jf4jifjj | 3944 | carol | ...

  Sometimes we may need a combined table for both INR and BTC withdraws sorted by time and search by max/offset This is not possible with two separate tables

  The MergedIndex object below takes care of this

  It provides a "merged table" M with the above two tables as "left-half" and "right-half" of that table

  The HalfTable encapsulates each half table

  case class HalfTable(db:DBManager, indexCol:Col, priKeyCol:Col, filterCol:Col, wheres:Where*){

  If sorting by time, then indexCol will be time. Each table should have a primary key column that can be uniqely used to reference a row Finally the filterCol is the one we will use to filter the results by (say userID). Each half table is declared using the above rule.

  The resulying MergedTable M will appear like this --------------------------------------

  indexCol	priKeyCol	filterCol
  23	wjdejduejd	alice
  45	gtfcnmecnv	bob
  54	4jto4rkmkc	alice
  20	ecjerjcruc	alice
  29	roijfoirjf	carol
  34	i4jf4jifjj	carol

  When giving a from-to search query (possibly with a filter on userID), the resulting output will be a (nested query) representing the set of ids from the priKeyCol that can be used to search the original tables

  so suppose if we search for time =< 30 and time >= 20 in decreasing order, the the getPriKeys will return a nested query that returns the following keys

  ecjerjcruc (corresponding to indexCol 20) wjdejduejd (corresponding to indexCol 23) roijfoirjf (corresponding to indexCol 29)

  similarly if we search for time =< 30 and time >= 20 in decreasing order with filter == "alice", the the getPriKeys will return a nested query that returns the following keys

  ecjerjcruc (corresponding to indexCol 20) wjdejduejd (corresponding to indexCol 23)

  ** A Nested query is an "lazy query", i.e., a query exactly like a normal query except that it has not yet been run. However, when it will run, it will return the above data. Examples of nested queries:

  SELECT amount FROM T1, (SELECT ID FROM .. AS T2) where T1.ID = T2.ID

  OR

  SELECT amount FROM T1 where T1.ID IN (SELECT ID FROM T2)

  In both examples the value inside ( ) is a nested query

  Now suppose M is going to used as a half table in another merged table T (say, transactions), then we can use connectToLeftOf to connect to left of T (we can use connectToRightOf to connect to right)

  Then whenever any entry is added to INR withdraws, it will first cause an entry to be added to M and then (through the chaning) to T (Note that we could have done the same thing by manually creating a MergedTable using M and accessing the values (indexCol, priKeyCol, filterCol) of that)

  Definition Classes

  db

• HalfTable
• MergedTable

org.sh.db.MergedIndex

HalfTable 