Compared to the unidirectional association app, we have to deal with a number of new technical issues:

Code each class of the JS class model as an ES6 class with implicit getters and setters:

These steps are discussed in more detail in the following sections.

For instance, the Publisher class from the JS class model is coded in the following way:

class Publisher {
  constructor ({name, address}) {
    this.name = name;
    this.address = address;
    // derived inverse reference property (inverse of Book::publisher)
    this._publishedBooks = {};  // initialize as an empty map
  }
  get name() {...}
  static checkName( n) {...}
  static checkNameAsId( n) {...}
  static checkNameAsIdRef( n) {...}
  set name( n) {...}
  get address() {...}
  static checkAddress( a) {...}
  set address( a) {...}
  get publishedBooks() {...}
  toString() {...}
  toJSON() {...}
}

Notice that the (derived) multi-valued reference property publishedBooks has no setter method and is not assigned in the constructor function because it is a read-only property that is assigned implicitly when its inverse master reference property Book::publisher is assigned.

Any setter for a reference property that is coupled to a derived inverse reference property (implementing a bidirectional association), now also needs to assign (or add/remove) inverse references to (or from) the corresponding (collection) value of the inverse reference property. An example of such a setter is publisher in the Book class:

set publisher( p) {
  if (!p) {  // the publisher reference is to be deleted/unset
    // delete the inverse reference in Publisher::publishedBooks
    delete this._publisher.publishedBooks[ this._isbn];
    // unset the publisher property
    delete this._publisher;
  } else {
    // p can be an ID reference or an object reference
    const publisher_id = (typeof p !== "object") ? p : p.name;
    const constraintViolation = Book.checkPublisher( publisher_id);
    if (constraintViolation instanceof NoConstraintViolation) {
      if (this._publisher) {
        // delete the inverse reference in Publisher::publishedBooks
        delete this._publisher.publishedBooks[this._isbn];
      }
      // create the new publisher reference
      this._publisher = Publisher.instances[ publisher_id];
      // add the new inverse reference to Publisher::publishedBooks
      this._publisher.publishedBooks[this._isbn] = this;
    } else {
      throw constraintViolation;
    }
  }
}

For any multi-valued reference property that is coupled to a derived inverse reference property, both the add and the remove method also have to assign/add/remove corresponding references to/from (the value set of) the inverse property.

For instance, for the multi-valued reference property Book::authors that is coupled to the derived inverse reference property Author::authoredBooks for implementing the bidirectional authorship association between Book and Author, the Book::addAuthor method is coded in the following way:

addAuthor( a) {
  // a can be an ID reference or an object reference
  const author_id = (typeof a !== "object") ? parseInt(a) : a.authorId;
  const validationResult = Book.checkAuthor( author_id);
  if (author_id && validationResult instanceof NoConstraintViolation) {
    // add the new author reference
    this._authors[author_id] = Author.instances[author_id];
    // automatically add the derived inverse reference
    this._authors[author_id].authoredBooks[this._isbn] = this;
  } else {
    throw validationResult;
  }
}

For the remove operation removeAuthor we obtain the following code:

removeAuthor( a) {
  // a can be an ID reference or an object reference
  const author_id = (typeof a !== "object") ? parseInt(a) : a.authorId;
  const validationResult = Book.checkAuthor( author_id);
  if (validationResult instanceof NoConstraintViolation) {
    // automatically delete the derived inverse reference
    delete this._authors[author_id].authoredBooks[this._isbn];
    // delete the author reference
    delete this._authors[author_id];
  } else {
    throw validationResult;
  }
}

In the object-to-storage conversion of a publisher or author object with toJSON(), the derived properties Publisher::publishedBooks and Author::authoredBooks are not included since their information is redundant (derived from the Book::publisher and Book::authors properties). For instance, the Author::toJSON function is coded in the following way:

toJSON() {
  var rec = {};
  // loop over all Author properties
  for (const p of Object.keys( this)) {
    // keep underscore-prefixed properties except "_authoredBooks"
    if (p.charAt(0) === "_" && p !== "_authoredBooks") {
      // remove underscore prefix
      rec[p.substr(1)] = this[p];
    }
  };
  return rec;
}

When a Book instance b, with a single reference b.publisher to a Publisher instance p and multiple references b.authors to Author instances, is destroyed, depending on the chosen deletion policy (1) CASCADE or (2) DROP-REFERENCES, (1) the dependent Publisher instance and Author instances have to be deleted first or (2) the derived inverse references have to be removed first (e.g., by removing b from p.publishedBooks). We assume Existential Independence for both associated object types and, consequently, implement the DROP-REFERENCES policy:

Book.destroy = function (isbn) {
  const book = Book.instances[isbn];
  if (book) {
    console.log( book.toString() + " deleted!");
    if (book.publisher) {
      // remove inverse reference from book.publisher
      delete book.publisher.publishedBooks[isbn];
    }
    // remove inverse references from all book.authors
    for (const authorID of Object.keys( book.authors)) {
      delete book.authors[authorID].authoredBooks[isbn];
    }
    // finally, delete book from Book.instances
    delete Book.instances[isbn];
  } else {
    console.log(`There is no book with ISBN ${isbn} in the database!`);
  }
};