Historical lookup indexed db

[shandilya3]

Description

IndexedDB for historical search
Wiki Doc: https://wiki.corp.adobe.com/display/Target/Historical+Events+Storage+-IndexedDB+-+In+Progress

To run locally, NPM link to this PR branch adobe/aepsdk-rulesengine-typescript#20

Related Issue

Motivation and Context

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Improvement (non-breaking change which does not add functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA or I'm an Adobe employee.
• I have made any necessary test changes and all tests pass.
• I have run the Sandbox successfully.

[shandilya3]

This is for local e2e test, will add dependency once rule engine changes are approved & published.

[carterworks]

We don't allow importing between components in Alloy. If this needs to be shared between the two components, put it into src/shared.

[carterworks]

The wrapping new Promise() is unnecessary and can be removed without effect. Returning something from a .then() is the same as resolving the Promise with that value.

[carterworks]

Same as before. If it needs to be shared across components, then it should be in the shared folder.

[carterworks]

Same as before. Wrapping it in new Promise() with the resolve is unnecessary.

[carterworks]

Ditto.

[carterworks]

shared folder.

[carterworks]

In the Identity component, we have a similar situation: we need to wait for the identity cookie before we firing off other requests. However, the awaitIdentityCookie() is implemented with Promises.

I think if you use Promises here, it would make the implementation a little neater and removes the need for waitForDBInitialization() and it's setTimeout().

For example, if you write setupIndexDB() like so…

export default () => {
  let dbPromise;
  const setupIndexedDB = () => {
    dbPromise = new Promise((resolve, reject) => {
      // set up login
    });
    // no need to expose the DB outside of this module
    return dbPromise.then(() => {});
  };
}

Then you can use dbPromise like this…

const addRecord = record => {
  return dbPromise.then(db => {
    const transaction = db.transaction("events", "readwrite");
    const objectStore = transaction.objectStore("events");
    const objectStoreRequest = objectStore.add(record);
    return new Promise((resolve, reject) => {
      objectStoreRequest.onsuccess = () => resolve(true);
      objectStoreRequest.onerror = (txEvent) => reject(txEvent.target.error);
    });
  })
};

And you don't need the setTimeout (which is kind of a code smell, in my opinion).

[carterworks]

new Promise() and resolve() are unnecessary.

[carterworks]

Please use the logger for logging messages.

[carterworks]

In the Identity component, we have a similar situation: we need to wait for the identity cookie before we firing off other requests. However, the awaitIdentityCookie() is implemented with Promises.

I think if you use Promises here, it would make the implementation a neater and removes the need for waitForDBInitialization() and it's setTimeout().

For example, if you write setupIndexDB() like so…

export default () => {
  /** @type {Promise<IDBDatabase>} */
  let dbPromise;
  const setupIndexedDB = () => {
    dbPromise = new Promise((resolve, reject) => {
      // set up login
    });
    // instead of returning a promise that resolves to 
    // db and exposes it outside of this module, return
    // a cleanup function
    return dbPromise.then(db => () => db.close());
  };
}

Then you can use dbPromise like this…

const addRecord = record => {
  return dbPromise.then(db => {
    const transaction = db.transaction("events", "readwrite");
    const objectStore = transaction.objectStore("events");
    const objectStoreRequest = objectStore.add(record);
    return new Promise((resolve, reject) => {
      objectStoreRequest.onsuccess = () => resolve(true);
      objectStoreRequest.onerror = (txEvent) => reject(txEvent.target.error);
    });
  })
};

And you don't need the setTimeout (which is kind of a code smell, in my opinion).

[carterworks]

In the Identity component, we have a similar situation: we need to wait for the identity cookie before we firing off other requests. However, the awaitIdentityCookie() is implemented with Promises.

I think if you use Promises here, it would make the implementation a little neater and removes the need for waitForDBInitialization() and it's setTimeout().

For example, if you write setupIndexDB() like so…

export default () => {
  let dbPromise;
  const setupIndexedDB = () => {
    dbPromise = new Promise((resolve, reject) => {
      // set up login
    });
    // no need to expose the DB outside of this module
    return dbPromise.then(() => {});
  };
}

Then you can use dbPromise like this…

const addRecord = record => {
  return dbPromise.then(db => {
    const transaction = db.transaction("events", "readwrite");
    const objectStore = transaction.objectStore("events");
    const objectStoreRequest = objectStore.add(record);
    return new Promise((resolve, reject) => {
      objectStoreRequest.onsuccess = () => resolve(true);
      objectStoreRequest.onerror = (txEvent) => reject(txEvent.target.error);
    });
  })
};

This way, you don't need waitForDBInitialization() with it's setTimeout() or getIndexDB() (which are kind of a code smells, in my opinion).

[shandilya3]

We realized IndexedDB is more limited than expected. It's not as efficient as we had planned. Example, you can not write standard sequel statements, nor can you ask for results to be sorted (by timestamp for example). These limitations make the solution less performant than what we've already got with localStorage. With that in mind, it was decided that it would be best to stick with the existing implementation with the expectation with some changes to expect there will always be iam.id and iam.eventType in historical rulesets for IAM on the web.
We can still continue iterating on the IndexedDB approach, but we'll need to add a service worker for performance, and configuration options to the rule engine, among other things. Since we will be adding a service worker for web push, Jason recommended revisiting IndexedDB at that time.