pure-orm 4.0.0-0 → 4.0.0-1

package/README.md

@@ -29,138 +29,39 @@ The name _**pure**ORM_ reflects both of these points - that it is _pure_ ORM (th
 
 #### Concepts
 
-A **Business Object** (BO) is a pure javascript object corresponding to a table.
+A **Model** is a pure javascript business object corresponding to a table.
 
+- In PureORM these pure business objects are referred to as "models".
 - They represent a row of the table data, but as pure javascript objects.
 - They are not connected to the database.
 - They are the subject of the app's business logic.
 - They will be full of userland business logic methods.
 - Their purity allows them to be easy to test/use.
-- These are also referred to as "models".
 
-A **Business Object Collection** (BO Collection) is a group of pure javascript objects.
+A **Collection** is a pure business object with a reference to a group of models.
 
-- If your query returns records for multiple business objects, a BO Collection will be created and returned.
-- You can create a BO Collection class for your business objects (in cases where it is useful to have business methods on the collection entity, not just each model entity).
+- If your query returns records for multiple models, a Collection will be created and returned.
+- You can create the Collection class (in cases where it is useful to have business methods on the collection object, not just each model object).
 
-A **Data Access Layer** (DAL) is a database-aware abstraction layer where native SQL is written.
+A **Data Access Layer** is a database-aware abstraction layer where native SQL is written.
 
 - This is not an "expresion language" or "query builder". There are not hundreds of methods mapping the complexity, expressiveness, and nuance of SQL to class objects.
 - Rather, is a data access layer in which native SQL is written, and which returns business objects (properly nested and structured).
 
-## Quick Example
-
-Using PureORM allows you to write code like this:
-
-```javascript
-// ./dal/person.js
-const getPerson = ({ id }) => {
-  const query = `
-    SELECT
-      ${orm.tables.person.columns},
-      ${orm.tables.job.columns},
-      ${orm.tables.employer.columns}
-    FROM person
-    JOIN job on person.id = job.person_id
-    JOIN employer on job.employer_id = employer.id
-    WHERE id = $(id)
-  `;
-  return orm.one(query, { id });
-};
-
-// ./controllers/rest/person.js
-const { getPerson } = require('./dal/person');
-const get = (req, res) => {
-  const person = await getPerson({ id: req.params.id });
-  res.json(person);
-};
-```
-
-Which a GET to that controller would return
-
-```javascript
-Person {
-  id: 55,
-  name: 'John Doe',
-  jobs: JobsCollection {
-    models: [
-      Job {
-        id: 277,
-        personId: 55,
-        employerId: 17,
-        startDate: '2020-01-01',
-        endDate: '2020-12-31',
-        employer: Employer {
-          id: 17,
-          name: 'Good Corp',
-        }
-      },
-      Job {
-        id: 278,
-        personId: 55,
-        employerId: 26,
-        startDate: '2021-01-01',
-        endDate: '2021-12-31',
-        employer: Employer {
-          id: 26,
-          name: 'Better Corp',
-        }
-      }
-    ]
-  }
-}
-```
-
-> This is a quick showcase. To see how to wire up this code, see the full [Practical Example](#practical-example) below.
-
-### Things to Note:
-
-- Our DAL function returns a single Person business object which is properly structured from the many relational row records!
-- Our query is executed with a `one` method. The ORM methods for `one`, `oneOrNone`, `many`, `any` ensure their count against the number of generated top level business objects - not the number of relational row records the sql expression returns!
-- Rather than manually specifying our columns in the sql select expression, we used the orm's getter for columns. This is purely a convenience method which namespaces each column with the table name prefix to ensure column names don't collide (for example, the person, job, and employer `id`s would collide if not namespaced, as would person and employer `name`s). You are welcome to do this by hand instead of using this convenience if you don't mind the tedium:
-  ```javascript
-  // ./dal/person.js
-  const getPerson = ({ id }) => {
-    // Example showing you can manually specify the select expression fields
-    // instead of using the orm's columns getter.
-    // Note: you must namespace the field with table name and hashtag.
-    const query = `
-      SELECT
-        person.id as "person#id",
-        person.name as "person#name",
-        job.id as "job#id",
-        job.person_id: "job#person_id",
-        job.employer_id: "job#employer_id",
-        job.start_date: "job#start_date",
-        job.end_date: "job#end_date",
-        employer.id as "employer#id",
-        employer.name as "employer#name"
-      FROM person
-      JOIN job on person.id = job.person_id
-      JOIN employer on job.employer_id = employer.id
-      WHERE id = $(id)
-    `;
-    return orm.one(query, { id });
-  };
-  ```
-
-## Usage
-
-The exports you'll use from pure-orm:
-
-- `create` is a factory to create your ORM. This factory function accepts an object with two properties.
-  - `getBusinessObjects` which is a function that returns an array of all your business object classes (where each business object must implement static `table` and `sqlColumnsData` fields.
-  - `db` which is an instance of the database driver.
-
 ## Practical Example
 
 Lets take a practical example to see all this in action. Lets fill in the backend for a tiny rest server for a person.
 
 Lets say we have a database with three tables: person, job, and employer. We want our rest server to return an payload like this for requests which the get method receive.
 
-```javascript
-// ./controllers/rest/person.js
-const get = (req, res) => {
+```typescript
+// app.ts
+import express, { Express, Request, Response } from 'express';
+
+const app: Express = express();
+const port = process.env.PORT;
+
+app.get('/rest/person', (req: Request, res: Response) => {
   const person = {
     id: 55,
     name: 'John Doe',
@@ -192,22 +93,43 @@ const get = (req, res) => {
     }
   };
   res.json(person);
-};
+});
+
+app.listen(port);
 ```
 
-Based on the tables, I know exactly how to query for this:
+Based on the tables with this data:
+
+**Person**
+| id | name |
+| --- | --- |
+| 55 | John Doe |
+
+**Employer**
+| id | name |
+| --- | --- |
+| 17 | Good Corp |
+| 26 | Better Corp |
+
+**Job**
+| id | personId | employerId | startDate | endDate |
+| --- | --- | --- | --- | ---|
+| 277 | 55 | 17 | 2020-01-01 | 2020-12-31 |
+| 278 | 55 | 26 | 2021-01-01 | 2021-12-31 |
+
+I know exactly how I want to query for it:
 
 ```sql
 SELECT *
 FROM person
 LEFT JOIN job on person.id = job.person_id
-JOIN employer on job.employer_id = employer.id
-WHERE id = 55;
+LEFT JOIN employer on job.employer_id = employer.id
+WHERE person.id = 55;
 ```
 
-I already know how to SQL, and don't want to spend the time mapping what I already know how to do onto a huge, niche, library-specific API.
+I already know how SQL, and don't want to spend the time mapping what I already know how to do onto a huge, niche, library-specific API.
 
-However, using this query with a database driver would give me a bunch of flat result records, not one object that is properly structed/nested like I want in my code, and with collided fields (id from all three tables, name from person and employer, etc).
+However, using this query with a database driver would give me a bunch of flat result records (not one object that is properly structed/nested) and with collided fields (id from all three tables, name from person and employer, etc).
 
 So, lets install PureORM and the database driver and get started!
 
@@ -220,14 +142,200 @@ npm install --save pure-orm
 npm install --save pg-promise
 ```
 
-### Step 2: Writing the Controller Code
+### Step 2: Creating the Business Objects
+
+Let's create a `/models` directory of business object classes for our database tables. These classes need to implement a static getter for `tableName` and `sqlColumnsData` to denote the database table and columns.
+
+```typescript
+// models/person.ts
+import { IModel, ICollection, IColumns, IEntity } from 'pure-orm';
+
+export const tableName: string = 'person';
+
+export const columns: IColumns = ['id', 'name'];
+
+export class Person implements IModel {
+  id: number;
+  name: string;
+  constructor(props) {
+    this.id = props.id;
+    this.name = props.name;
+  }
+  // any business methods...
+}
+
+export const personEntity: IEntity = { tableName, columns, Model: Person };
+```
+
+```typescript
+// models/job.ts
+import { IModel, ICollection, IColumns, IEntity } from 'pure-orm';
+import { Person } from './person';
+import { Employer } from './employer';
+
+export const tableName: string = 'job';
+
+export const columns: IColumns = [
+  'id',
+  { column: 'person_id', references: Person },
+  { column: 'employer_id', references: Employer },
+  'start_date',
+  'end_date'
+];
+
+export class Job implements IModel {
+  id: number;
+  personId: number;
+  person?: Person;
+  employerId: number;
+  employer: Employer;
+  startDate: Date;
+  endDate: Date;
+  constructor(props) {
+    this.id = props.id;
+    this.personId = props.personId;
+    this.person = props.person;
+    this.employerId = props.employerId;
+    this.employer = props.employer;
+    this.startDate = props.startDate;
+    this.endDate = props.endDate;
+  }
+  // any business methods...
+}
+
+export const JobEntity: IEntity = { tableName, columns, Model: Job };
+```
+
+```typescript
+// models/employer.ts
+import { IModel, ICollection, IColumns, IEntity } from 'pure-orm';
+
+export const tableName: string = 'employer';
+
+export const columns: IColumns = ['id', 'name'];
+
+export class Employer implements IModel {
+  id: number;
+  name: string;
+  constructor(props: IEmployerProps) {
+    this.id = props.id;
+    this.name = props.name;
+  }
+  // any business methods...
+}
+
+export const EmployerEntity: IEntity = { tableName, columns, Model: Employer };
+```
+
+We've not got our three entities that relate our table data to our business objects.
 
-Lets remove our hardcoded example, and write our contoller code using functions we want to exist and will create.
+### Step 3: Creating our ORM
+
+First we create our database driver:
+
+```typescript
+// ./factories/db.ts
+import pgPromise from 'pg-promise';
+const pgp = pgPromise();
+const connectionObject = {
+  host: process.env.DB_HOSTNAME,
+  port: process.env.DB_PORT,
+  database: process.env.DB_NAME,
+  user: process.env.DB_USERNAME,
+  password: process.env.DB_PASSWORD
+};
+export const db = pgp(connectionObject);
+```
+
+We can now create our ORM, which layers atop the database driver to do the object relational mapping of raw sql row data to nest objects. (Besides using the `db` instance directly, the orm also offers access to the db directly (`orm.db`) for anytime this object relational mapping isn't desired.
+
+```typescript
+// factories/orm.ts
+import { create } from 'pure-orm';
+import { db } from './db';
+import { personEntity } from '../models/person';
+import { jobEntity } from '../models/job';
+import { employerEntity } from '../models/employer';
+const orm = create({
+  getEntities: () => [personEntity, jobEntity, employerEntity],
+  db
+});
+export default orm;
+```
+
+### Step 4: Creating our Data Access Layer
+
+Let's now create a data access directory with a person file for data access operations related to a person.
+
+```typescript
+// data-access/person.ts
+import orm from '../factories/orm';
+import { Person } from '../models/person';
+
+export const getPerson = (id: number): Person => {
+  const query = `
+    SELECT
+      ${orm.tables.person.columns},
+      ${orm.tables.job.columns},
+      ${orm.tables.employer.columns}
+    FROM person
+    LEFT JOIN job on person.id = job.person_id
+    LEFT JOIN employer on job.employer_id = employer.id
+    WHERE id = $(id)
+  `;
+  return orm.one(query, { id });
+};
+```
+
+Some things to note:
+
+- Our data access function returns a single Person model which is properly structured from the many relational row records!
+- Our query is executed with a `one` method. The ORM methods for `one`, `oneOrNone`, `many`, `any` ensure their count against the number of generated top level models - not the number of relational row records the sql expression returns!
+- Rather than manually specifying our columns in the sql select expression, we used the orm's getter for columns. This is purely a convenience method which namespaces each column with the table name prefix to ensure column names don't collide (for example, the person, job, and employer `id`s would collide if not namespaced, as would person and employer `name`s). You are welcome to do this by hand instead of using this convenience if you don't mind the tedium:
+
+  ```typescript
+  // data-access/person.ts
+  import orm from '../factories/orm';
+  import { Person } from '../models/person';
+
+  const getPerson(id) {
+    // Example showing you can manually specify the select expression fields
+    // instead of using the orm's columns getter.
+    // Note: you must namespace the field with table name and hashtag.
+    const query = `
+      SELECT
+        person.id as "person#id",
+        person.name as "person#name",
+        job.id as "job#id",
+        job.person_id: "job#person_id",
+        job.employer_id: "job#employer_id",
+        job.start_date: "job#start_date",
+        job.end_date: "job#end_date",
+        employer.id as "employer#id",
+        employer.name as "employer#name"
+      FROM person
+      LEFT JOIN job on person.id = job.person_id
+      LEFT JOIN employer on job.employer_id = employer.id
+      WHERE id = $(id)
+    `;
+    return orm.one(query, { id });
+  }
+  module.exports = getPerson;
+  ```
+
+### Step 5: Writing the Controller Code
+
+We can now return to our controller code, and use our person data access function.
 
 ```diff
-// ./controllers/rest/person.js
-+const { getPerson } = require('./dal/person');
-const renderProfile = (req, res) => {
+// app.ts
+import express, { Express, Request, Response } from 'express';
++import { getPerson } from './data-access/person';
+
+const app: Express = express();
+const port = process.env.PORT;
+
+app.get('/rest/person', (req: Request, res: Response) => {
 - const person = {
 -   id: 55,
 -   name: 'John Doe',
@@ -241,7 +349,7 @@ const renderProfile = (req, res) => {
 -         endDate: '2020-12-31',
 -         employer: {
 -           id: 17,
--           name: 'Good Corp',
+-           name: 'Good Corp'
 -         }
 -       },
 -       {
@@ -252,185 +360,198 @@ const renderProfile = (req, res) => {
 -         endDate: '2021-12-31',
 -         employer: {
 -           id: 26,
--           name: 'Better Corp',
+-           name: 'Better Corp'
 -         }
 -       }
 -     ]
 -   }
 - };
-+ const person = getPerson({ id: req.params.id });
-  res.render('profile.html', person);
-```
-
-This looks nice, now let's create the necessary bo and function in the dal.
-
-### Step 3: Creating the Business Objects
-
-Let's create a `/bo` directory and the classes we want.
-
-```javascript
-// ./bo/person.js
-class Person {
-  static tableName = 'person';
-  static sqlColumnsData = ['id', 'name'];
-  // any other business methods...
-}
-module.exports = Person;
-```
++ const person = getPerson(req.params.id);
+  res.json(person);
+});
 
-```javascript
-// ./bo/job.js
-const Person = require('./person');
-const Employer = require('./employer');
-
-class Job {
-  static tableName = 'job';
-  static sqlColumnsData = [
-    'id',
-    { column: 'person_id', references: Person },
-    { column: 'employer_id', references: Employer },
-    'start_date',
-    'end_date'
-  ];
-  // any other business methods...
-}
-module.exports = Job;
+app.listen(port);
 ```
 
-```javascript
-// ./bo/employer.js
-class Employer {
-  static tableName = 'employer';
-  static sqlColumnsData = ['id', 'name'];
-  // any other business methods...
-}
-module.exports = Employer;
-```
+That's it! This controller code now works! The `getPerson` function returns a properly structured business object as we desire.
 
-We've not got our three business object classes. To review, each business object class has:
+## API
 
-- A static `tableName` property to denote which table results this class is for.
-- A static `sqlColumnsData` property to enumerate the table columns.
+### `create`
 
-### Step 4: Creating our ORM
+```typescript
+function create(options: {
+  getEntities: () => Array<IEntity>;
+  db: DataBaseDriver;
+}): PureORM;
+```
 
-```javascript
-// ./factories/orm.js
-const db = require('./db');
-const { create } = require('pure-orm');
-const Person = require('./person');
-const Job = require('./job');
-const Employer = require('./employer');
+The factory function for creating your ORM.
 
-const orm = create({
-  db,
-  getBusinessObjects: () => [Person, Job, Employer]
-});
-module.exports = BaseBO;
-```
+**Parameters**
 
-### Step 4: Creating the DAL function
+- `getEntities: () => Array<IEntity>` - A function which returns an array of all the business object class entity configuration objects.
+- `db: <DataBaseDriverInstance>` - A database driver instance.
 
-```javascript
-// ./dal/person.js
-const orm = require('../factories/orm');
+**Return Value**
 
-const getPerson({ id }) {
-  const query = `
-    SELECT
-      ${Person.getSQLSelectClause()},
-      ${Job.getSQLSelectClause()},
-      ${Employer.getSQLSelectClause()}
-    FROM person
-    JOIN job on person.id = job.person_id
-    JOIN employer on job.employer_id = employer.id
-    WHERE id = $(id)
-  `;
-  return orm.one(query, { id });
+Your `PureORM` instance, which is of this interface:
+
+```typescript
+interface PureORM {
+  /* ------------------------------------------------------------------------*/
+  /* Query methods ----------------------------------------------------------*/
+  /* ------------------------------------------------------------------------*/
+
+  /* Note these query methods ensure their count against the number of
+   * generated top level business objects which are created - not the number
+   * of relational rows returned from the database driver! Thus, for example,
+   * `one` understands that there may be multiple result rows (which a
+   * database driver's `one` query method would throw at) but which correctly
+   * nest into one Model.)
+   */
+
+  // Execute a query returning a single model, or throws.
+  one: <T extends IModel>(
+    query: string,
+    values?: object,
+    errorHandler = defaultErrorHandler
+  ) => T;
+
+  // Execute a query returning either single model or undefined, or throws.
+  oneOrNone: <T extends IModel>(
+    query: string,
+    values?: object,
+    errorHandler = defaultErrorHandler
+  ) => T | void;
+
+  // Execute a query returning a Collection with at least one model, or throws.
+  many: <T extends ICollection<IModel>>(
+    query: string,
+    values?: object,
+    errorHandler = defaultErrorHandler
+  ) => T;
+
+  // Execute a query returning a Collection.
+  any: <T extends ICollection<IModel>>(
+    query: string,
+    values?: object,
+    errorHandler = defaultErrorHandler
+  ) => T | void;
+
+  // Execute a query returning null.
+  none: (
+    query: string,
+    values?: object,
+    errorHandler = defaultErrorHandler
+  ) => void;
+
+  /* ------------------------------------------------------------------------*/
+  /* Built-in basic CRUD functions ------------------------------------------*/
+  /* ------------------------------------------------------------------------*/
+
+  /* These are just provided because they are so common and straight-forward.
+   * While the goal of this library is foster writing SQL in your data access
+   * layer (which returns pure business objects) some CRUD operations are so
+   * common they are included in the ORM. Feel free to completely disregard
+   * if you want to write these in your data access layer yourself.
+   */
+
+  getMatching: <T extends IModel>(model: T) => T;
+  getOneOrNoneMatching: <T extends IModel>(model: T) => T | void;
+  getAnyMatching: <T extends ICollection<IModel>>(model: IModel) => T | void;
+  getAllMatching: <T extends ICollection<IModel>>(model: IModel) => T;
+  create: <T extends IModel>(model: T) => T;
+  update: <T extends IModel>(model: T, { on = 'id' } = {}) => T;
+  _delete: <T extends IModel>(model: T) => void;
+  deleteMatching: <T extends IModel>(model => T);
+
+  /* ------------------------------------------------------------------------*/
+  /* Built-in basic CRUD functions ------------------------------------------*/
+  /* ------------------------------------------------------------------------*/
+
+  /* The tables property gives access to the sql select clause string for
+   * each entity based on it's `displayName`. This property can be used when
+   * writing raw SQL as the select clause, which handles quoting column names
+   * and namespacing them to the table to avoid collisions and as required
+   * for PureORM mapping.
+   */
+
+  tables: { [key:string]: { [key: string]: string; }};
 }
-module.exports = getPerson;
 ```
 
-Notice that we're using `orm.one`, which is what we want. The DAO methods for `one`, `oneOrNone`, `many`, `any` ensure their count against the number of generated top level business objects - not the number of rows the sql expression returns!
+## FAQ
 
-### Step 6: Creating the Database Driver Instance
+### Can you show the business objects of a more complex entity?
 
-The last step is creating the datebase driver, that we had imported up in `./factories/orm`.
+```typescript
+import { IModel, ICollection, IColumns, IEntity } from 'pure-orm';
 
-```javascript
-// ./factories/db.js
-const pgPromise = require('pg-promise');
-const pgp = pgPromise();
-module.exports = pgp({
-  host: process.env.DB_HOSTNAME,
-  port: process.env.DB_PORT,
-  database: process.env.DB_NAME,
-  user: process.env.DB_USERNAME,
-  password: process.env.DB_PASSWORD
-});
-```
+export const tableName: string = 'library_v2';
 
-That's it! Our example controller code now works! The `getPerson` function in our data access layer now returns a properly structured business object as we desire.
+export const columns: IColumns = [
+  'id',
+  'name',
+  { column: 'is_ala_member', property: 'isALAMember' },
+  { column: 'address_id', references: Address }
+];
 
-## FAQ
+export const displayName = 'library';
+export const collectionDisplayName = 'libraries';
 
-### Can you show a more complex business object and collection?
+interface ILibraryProps {
+  id: number;
+  name: string;
+  isALAMember: string;
+  addressId: number;
+  address: Address;
+}
 
-```javascript
-// ./bo/library.js
-const Libraries = require('./libraries');
-class Library {
-  get BoCollection() {
-    return Libraries;
-  }
-  static get tableName() {
-    return 'library_v2';
-  }
-  static get displayName() {
-    // If we didn't provide this static field, in javascript an object
-    // referencing a library bo would use `libraryV2` as the property name.
-    return 'library';
-  }
-  static get sqlColumnsData() {
-    return [
-      'id',
-      'name',
-      { column: 'is_ala_member', property: 'isALAMember' },
-      { column: 'address', references: Address }
-    ];
+export class Library implements IModel {
+  id: number;
+  name: string;
+  constructor(props: ILibraryProps) {
+    this.id = props.id;
+    this.name = props.name;
+    this.isALAMember = props.isALAMember;
+    this.addressId = props.addressId;
+    this.address = props.address;
   }
   aBussinessObjectMethod() {}
   anotherBussinessObjectMethod() {}
 }
-```
 
-```javascript
-// ./bo/libraries.js
-class Library {
-  static get Bo() {
-    return require('./person'); // eslint-disable-line
-  }
-  static get displayName() {
-    // If we didn't provide this static field, in javascript an object
-    // referencing this collection would use `librarys` as the property name.
-    return 'libraries';
+export class Persons implements ICollection<Person> {
+  models: Array<Person>;
+  constructor({ models }: any) {
+    this.models = models;
+    return this;
   }
   aCollectionMethod() {}
   anotherCollectionMethod() {}
 }
+
+export const personEntity: IEntity = {
+  tableName,
+  displayName,
+  collectionDisplayName,
+  columns,
+  Model: Person,
+  Collection: Persons
+};
 ```
 
 ### If I use PureORM do I have to re-invent all the super basic CRUD methods?
 
 The goal of PureORM is to foster writing SQL and receiving pure business objects. That said, some SQL is so common that we preload the created ORM with with some basic CRUD operations.
 
-For example, rather than every entity's DAL needing basic get, create, etc method, you can use:
+For example, rather than every entity needing data access operatons for get, create, etc method, you can use built-in orm functions.
 
-```javascript
-// ./controllers/rest/person.js
-const get = (req, res) => {
+```typescript
+app.get('/rest/person', (req: Request, res: Response) => {
   if (req.params.id) {
-    return res.json(await orm.get(new Person({ id })));
+    return res.json(await orm.getMatching(new Person({ id })));
   }
   if (req.query.name) {
     return res.json(
@@ -443,12 +564,12 @@ const get = (req, res) => {
 };
 ```
 
-At any point you can ditch these built-ins and write some SQL in a DAL function.
+At any point you can ditch these built-ins and write some SQL in a data access function.
 
-```javascript
-// ./controllers/rest/person.js
-const { getPerson, getPeopleWithName } = require('../../dal/person');
-const get = (req, res) => {
+```typescript
+import { getPerson, getPeopleWithName } from '../../data-access/person';
+
+app.get('/rest/person', (req: Request, res: Response) => {
   if (req.params.id) {
     return res.json(await getPerson(id));
   }
@@ -465,13 +586,13 @@ const get = (req, res) => {
 
 Traditional/stateful ORMs offer a dialetic-generic, chainable object api for expressing underlying SQL - thus solving for database "lock-in" as well the inability of string queries compose easily. PureORM takes the approach that the tradeoff of developers having to learn the huge surface area of of a query builder, and having to map the complexity and nuance of SQL to it, are simply not worth the cost, and so is premised on not using a query building library. PureORM sees writing straight SQL heaviliy as a feature, not a defect needing solved, and not eclipsed by the composibility of a query builder.
 
-### Will I then have dozens of similar DAL functions, since strings aren't as composable as stateful ORM builder builder APIs?
+### Will I then have dozens of similar data access functions, since strings aren't as composable as stateful ORM builder builder APIs?
 
 There is still a lot of composibility possible with functions returning strings (someone create an Issue if you want to see examples used in the Kujo codebase), but in general yes, there is more repitition. Most of this remaining repitition is not something I think is a defect (though those obsessed with DRY would disagree). The only "defect" of this repitition is that there may be more than one similiar method (for example a "get" that does certain joins vs others), and differentiating the large query in a function name can be lengthy/annoying. In these cases where composing functions doesn't bring the number of similar functions methods to only one, rather than distilling these large queries into the function name (eg, getPersonWithJobsAndEmployers), I usually just opt for a small arbitrary hash at the end of the short name (eg, getXTW instead of getPersonWithJobsAndEmployers, getRJF instead of getPersonWithFriendsLocatedNearANewFriendRequest, etc).
 
 ### Does PureORM abstract away the database driver?
 
-No, the whole premise of PureORM is to offer a library to aid the use of writing SQL. The datebase driver is always available to you (at `orm.db`) if you wish to use it directly with no PureORM mappings, or just import it. In my experience, a small percentage of highly complex queries looking for sums or counts in my DAL use the database driver directly.
+No, the whole premise of PureORM is to offer a library to aid the use of writing SQL. The datebase driver is always available to you (at `orm.db`) if you wish to use it directly with no PureORM mappings, or just import it. In my experience, a small percentage of highly complex queries looking for sums or counts in my data access layer use the database driver directly.
 
 The only difference is how the SQL is invoked: `orm.one(query, {})` vs `orm.db.one(query, {})`
 
@@ -483,7 +604,7 @@ Yes, if you'd like to get the mapping while also passing through some select exp
 const getBloggerPayout = ({ id, startDate, endDate }) => {
   const query = `
     SELECT
-      ${Person.getSQLSelectClause()},
+      ${orm.tables.person.columns},
       COALESCE(SUM(article.blogger_payout), 0) as meta_amount
     FROM
       person
@@ -518,69 +639,6 @@ PureORM
 - PureORM is more than just the preference against the query builder portion of Stateful ORMs
 - PureORM is the preference against stateful, db-connected objects: PureORM resolves result rows to _pure_ business objects. This purity in business objects fosters a clean layer of the business layer from the data access layer, as well as ensuring the very best in performance (eg, the [N+1 problem](https://docs.sqlalchemy.org/en/13/glossary.html#term-n-plus-one-problem) can't exist with pure objects).
 
-## API
-
-### Interfaces
-
-#### `PureORMEntity`
-
-An interface which your business object classes need to implement.
-
-- `static get tableName(): string` - Returns the string table name which the business object associates with from the database.
-- `static get sqlColumnsData(): Array<string|ColumnData>` - Returns an array of the database column data. The type is either:
-  - `ColumnData {column, property?, references?, primaryKey?}`
-    - `column: string` - The sql column name
-    - `propery: string` - The javascript property name for this column (defaults to camelCase of `column`)
-    - `references: Bo` - The relationship to another Bo (defaults to null)
-    - `primaryKey: boolean` - Is this column (part of) the primary key (defaults to false)
-  - `string` - If a string, it is applied as the `column` value, with all others defaulted.
-  - (Note: if there is no primary key, `id` is defaulted)
-- `get BoCollection()?: BoCollection` - (Optional) returns the business object collection class constructor.
-- `static get displayName()?: string` - (Optional) returns the string display name of the business object (defaults to camelcase of tableName)
-
-#### `PureORMCollection`
-
-An abstract class which is the base class your Bo Collection classes extend.
-
-- `static get Bo(): BO` - Returns the individual (singular) business object class constructor.
-- `get displayName()?: BO` - (Optional) returns the string display name of the business object collection (defaults to bo displayName with an "s")
-
-#### `create`
-
-The factory function for creating your ORM.
-
-**Parameters**
-
-- `getBusinessObjects: () => Array<BusinessObject>` - A function which returns an array of all the business objects.
-- `db: <DataBaseDriverInstance>` - A database driver instance.
-
-**Return Value**
-
-Your ORM.
-
-It has the following query methods:
-
-- `one(query: string, params: object)` - executes a query and returns a Bo, or throws.
-- `oneOrNone(query: string, params: object)` - executes a query and returns a Bo or undefined, or throws.
-- `many(query: string, params: object)` - executes a query and returns a BoCollection with at least one model, or throws.
-- `any(query: string, params: object)` - executes a query and returns a BoCollection.
-- `none(query: string, params: object)` - executes a query and returns null.
-
-(Note these orm query methods ensure their count against the number of generated top level business objects are created - not the number of relational rows returned from the database driver! Thus, for example, `one` understands that there may be multiple result rows (which a database driver's `one` query method would throw at) but which correctly nest into one BO.)
-
-Built-in "basic" / generic crud functions
-
-- `getMatching(bo: BaseBO)`
-- `getOneOrNoneMatching(bo: BaseBO)`
-- `getAnyMatching(bo: BaseBO)`
-- `getAllMatching(bo: BaseBO)`
-- `create(bo: BaseBO)`
-- `update(bo: BaseBO)`
-- `delete(bo: BaseBO)`
-- `deleteMatching(bo: BaseBO)`
-
-These are just provided because they are so common and straight-forward. While the goal of this library is foster writing SQL in your DAL (which returns pure business objects) some CRUD operations are so common they are included in the ORM. Feel free to completely disregard if you want to write these in your DAL yourself.
-
 ## Current Status
 
 #### Current Limitations (PRs welcome!)