pure-orm 2.2.0 → 4.0.0-0

package/README.md

@@ -25,9 +25,7 @@ The name _**pure**ORM_ reflects both of these points - that it is _pure_ ORM (th
 
 #### Philosophy
 
-- Write _native_, _unobstructed_ SQL in a "data access object" layer which returns _pure_ "business objects" to be used in the app's business logic.
-- Have _database-connected_ "data access objects" which allow the unobstructed writing of normal SQL.
-- Have the "data access objects" returning the pure business objects.
+- Write _native_, _unobstructed_ SQL in a "data access layer" which returns _pure_ "business objects" to be used in the app's business logic.
 
 #### Concepts
 
@@ -45,41 +43,41 @@ A **Business Object Collection** (BO Collection) is a group of pure javascript o
 - 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).
 
-A **Data Access Object** (DAO) is a database-aware abstraction layer where native SQL is written.
+A **Data Access Layer** (DAL) 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).
-- By convention, they may also accept business objects as inputs (to get, create, or update records) - but this is just a convention (necessary input data can be passed as separate arguments, or however).
 
 ## Quick Example
 
 Using PureORM allows you to write code like this:
 
 ```javascript
-class PersonDAO extends BaseDAO {
-  get({ 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 this.one(query, { id });
-  }
-}
-```
-
-And use it like this:
+// ./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 });
+};
 
-```javascript
-const person = await personDAO.get({ id: 55 });
-console.log(person);
+// ./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,
@@ -117,62 +115,52 @@ Person {
 
 ### Things to Note:
 
-- Our DAO 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 DAO 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 use the business object's `getSQLSelectClause`. 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 the convenience methods (as were used above), if you don't mind the tedium:
+- 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
-  class PersonDAO extends BaseDAO {
-    get({ id }) {
-      // Example showing you can manually specific the select expression fields
-      // instead of using a business object's `getSQLSelectClause` convenience
-      // method. 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 this.one(query, { id });
-    }
-  }
+  // ./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
 
-### Ways of Using PureORM
-
-PureORM can work with no integration with your database driver. This is the strictest usage of PureORM. Going this route, the only export you use from PureORM is the factory to create your base bo constructor (`createBaseBO`) and optionally a base bo collection constructor (`BaseBoCollection`).
-
-PureORM also can wrap your database driver to make the API slightly less redundant. In this case you'll use the export which is a factory to create a base dao constructor (`createBaseDAO`). When you use this PureORM in this way, your DAO also inherits a handful of convenience methods for basic CRUD operations.
+The exports you'll use from pure-orm:
 
-Overview of the API (full [API details](#api) further down):
-
-- `createBaseBO` is a factory to create a base bo constructor. This factory method accepts a single argument: `getBusinessObjects` which is a function that returns an array of all your business object classes. You extend this class for all your business objects, and for each of these you must provide static `table` and `sqlColumnsData` fields. There are a number of other methods you can override from base to accomodate more advanced usage (including a `BoCollection` field to reference a custom class you want used for the collection).
-- `BaseBoCollection` can be used as the base class for any bo collection classes you make. Sometimes it can be useful to have business methods on the collection entity (not just each model entity) and so you can create such a class by extending `BaseBoCollection` and providing a `BoCollection` field on the business object model class.
-
-If you would like PureORM to wrap your database driver, you'll also use:
-
-- `createBaseBO` is a factory to create a base dao constructor. This factory method accepts two arguments: `db` which is your database driver, and optionally `logError` which logs any database errors. You extend this class for all your dao objects, and for each of these you must provide a `Bo` field in the class which references the busines object this class is used for.
+- `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 web page renderer.
+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 have a profile.html template set up so that if I hard code data like below, it renders our page.
+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/pages/person.js
-const renderProfile = (req, res) => {
+// ./controllers/rest/person.js
+const get = (req, res) => {
   const person = {
     id: 55,
     name: 'John Doe',
@@ -203,7 +191,7 @@ const renderProfile = (req, res) => {
       ]
     }
   };
-  res.render('profile.html', person);
+  res.json(person);
 };
 ```
 
@@ -212,7 +200,7 @@ Based on the tables, I know exactly how to query for this:
 ```sql
 SELECT *
 FROM person
-JOIN job on person.id = job.person_id
+LEFT JOIN job on person.id = job.person_id
 JOIN employer on job.employer_id = employer.id
 WHERE id = 55;
 ```
@@ -221,7 +209,7 @@ I already know how to SQL, and don't want to spend the time mapping what I alrea
 
 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).
 
-So, lets install PureOrm and the database driver and get started!
+So, lets install PureORM and the database driver and get started!
 
 ### Step 1: Installing PureORM and the Database Driver
 
@@ -237,8 +225,8 @@ npm install --save pg-promise
 Lets remove our hardcoded example, and write our contoller code using functions we want to exist and will create.
 
 ```diff
-// ./controllers/pages/person.js
-+const personDAO = require('./dao/person');
+// ./controllers/rest/person.js
++const { getPerson } = require('./dal/person');
 const renderProfile = (req, res) => {
 - const person = {
 -   id: 55,
@@ -270,11 +258,11 @@ const renderProfile = (req, res) => {
 -     ]
 -   }
 - };
-+ const person = personDAO.get({ id: req.params.id });
++ const person = getPerson({ id: req.params.id });
   res.render('profile.html', person);
 ```
 
-This looks nice, now let's create the dao and bo necessary.
+This looks nice, now let's create the necessary bo and function in the dal.
 
 ### Step 3: Creating the Business Objects
 
@@ -282,9 +270,7 @@ Let's create a `/bo` directory and the classes we want.
 
 ```javascript
 // ./bo/person.js
-const Base = require('./base');
-
-class Person extends Base {
+class Person {
   static tableName = 'person';
   static sqlColumnsData = ['id', 'name'];
   // any other business methods...
@@ -294,11 +280,10 @@ module.exports = Person;
 
 ```javascript
 // ./bo/job.js
-const Base = require('./base');
 const Person = require('./person');
 const Employer = require('./employer');
 
-class Job extends Base {
+class Job {
   static tableName = 'job';
   static sqlColumnsData = [
     'id',
@@ -314,9 +299,7 @@ module.exports = Job;
 
 ```javascript
 // ./bo/employer.js
-const Base = require('./base');
-
-class Employer extends Base {
+class Employer {
   static tableName = 'employer';
   static sqlColumnsData = ['id', 'name'];
   // any other business methods...
@@ -329,99 +312,50 @@ We've not got our three business object classes. To review, each business object
 - A static `tableName` property to denote which table results this class is for.
 - A static `sqlColumnsData` property to enumerate the table columns.
 
-The last business object we have to make is the `Base` one all of our above model classes extend. In order for any business model to properly structure/nest any other business object, each business object needs to know about every other business object. We do this by providing a `getBusinessObjects` method to our `createBaseBO` factory. (There is of course a circular dependency between the base class needing all classes that will end up being created which extend it, and using a function allows us to get around this circular dependency.)
+### Step 4: Creating our ORM
 
 ```javascript
-// ./bo/base.js
-const { createBaseBO } = require('pure-orm');
-
-const BaseBO = createBaseBO({
-  getBusinessObjects: () => [
-    require('./person'), // eslint-disable-line
-    require('./job'), // eslint-disable-line
-    require('./employer') // eslint-disable-line
-  ]
+// ./factories/orm.js
+const db = require('./db');
+const { create } = require('pure-orm');
+const Person = require('./person');
+const Job = require('./job');
+const Employer = require('./employer');
+
+const orm = create({
+  db,
+  getBusinessObjects: () => [Person, Job, Employer]
 });
 module.exports = BaseBO;
 ```
 
-### Step 4: Creating the DAO Object
-
-At this point, the path diverges for if you want to PureORM in the strictest/narrowest way, or in the more integrated way.
-
-Either way lets create a `./dao` directory and a `person.js` file.
-
-**If you want to use it in the narrowest way:**
-
-We'll import the database driver (`db`) and use it directly, and then call our ORM method on the results.
+### Step 4: Creating the DAL function
 
 ```javascript
-// ./dao/person.js
-const { db } = require('../factories/db');
-const Person = require('../business-objects/person');
-class PersonDAO {
-  async get({ 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)
-    `;
-    const rawResultRows = await db.many(query, { id });
-    return Person.createOneFromDatabase(rawResultRows);
-  }
-}
-module.exports = new PersonDAO();
-```
-
-Notice we are using the _one_ method `createOneFromDatabase` which is what we want since we are creating _one_ person, even though we use _many_ for the database driver. From the database driver's perspective there are many relational result row; however, from our perspective, these compose _one_ properly structured person. The create from database methods (`createOneFromDatabase`, `createOneOrNoneFromDatabase`, `createManyFromDatabase`, `createFromDatabase` for any) ensure their count against the number of generated top level business objects - not the number of rows the sql expression returns!
-
-If you are opting for this strict/narrow usage of PureORM, you're done! The DAO get method returns the relational result rows properly structured as we needed them to be. (Step 6 just shows us creating the database driver since we import a database driver - but it has nothing specific to PureORM).
-
-**If you want to use PureORM in the more integrated way:**
+// ./dal/person.js
+const orm = require('../factories/orm');
 
-```javascript
-// ./dao/person.js
-const BaseDAO = require('../dao/base');
-const Person = require('../business-objects/person');
-class PersonDAO extends BaseDAO {
-  Bo = Person;
-  get({ 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 this.one(query, { id });
-  }
+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 });
 }
-module.exports = new PersonDAO();
+module.exports = getPerson;
 ```
 
-Notice that we're using `this.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!
-
-### Step 5: Creating the BaseDAO
-
-Our PersonDAO extends BaseDAO, so lets create that by passing our database driver and optioanlly an error logger.
-
-```javascript
-// ./dao/base.js
-const { db } = require('../factories/db');
-const constructor = createBaseDAO({ db, logError: console.log.bind(console) });
-```
+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!
 
-### Step 6: Creating Database Driver Instance
+### Step 6: Creating the Database Driver Instance
 
-The last step is creating the datebase driver. Let's create a `factories` directory, and add this there.
+The last step is creating the datebase driver, that we had imported up in `./factories/orm`.
 
 ```javascript
 // ./factories/db.js
@@ -431,12 +365,12 @@ module.exports = pgp({
   host: process.env.DB_HOSTNAME,
   port: process.env.DB_PORT,
   database: process.env.DB_NAME,
-  user: DB_USERNAME,
-  password: DB_PASSWORD
+  user: process.env.DB_USERNAME,
+  password: process.env.DB_PASSWORD
 });
 ```
 
-That's it! Our example controller code now works! The DAO get method returns a properly structured business object as we desire.
+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.
 
 ## FAQ
 
@@ -445,7 +379,7 @@ That's it! Our example controller code now works! The DAO get method returns a p
 ```javascript
 // ./bo/library.js
 const Libraries = require('./libraries');
-class Library extends Base {
+class Library {
   get BoCollection() {
     return Libraries;
   }
@@ -465,12 +399,14 @@ class Library extends Base {
       { column: 'address', references: Address }
     ];
   }
+  aBussinessObjectMethod() {}
+  anotherBussinessObjectMethod() {}
 }
 ```
 
 ```javascript
 // ./bo/libraries.js
-class Library extends Base {
+class Library {
   static get Bo() {
     return require('./person'); // eslint-disable-line
   }
@@ -486,26 +422,65 @@ class Library extends Base {
 
 ### If I use PureORM do I have to re-invent all the super basic CRUD methods?
 
-If you're using PureORM in the strict usage, then yes - it's scope is limited to a business object's mapping relational result rows to pure objects. If you are using PureORM in the more integrated usage extending the BaseDAO class, then you receive a handful of convenience methods for basic CRUD operations. At any point, you could override these convenience 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:
+
+```javascript
+// ./controllers/rest/person.js
+const get = (req, res) => {
+  if (req.params.id) {
+    return res.json(await orm.get(new Person({ id })));
+  }
+  if (req.query.name) {
+    return res.json(
+      await orm.getAnyMatching(new Person({ name: req.query.name }))
+    );
+  }
+  res
+    .status(404)
+    .json({ error: 'Please specify an id or provide a name filter' });
+};
+```
+
+At any point you can ditch these built-ins and write some SQL in a DAL function.
+
+```javascript
+// ./controllers/rest/person.js
+const { getPerson, getPeopleWithName } = require('../../dal/person');
+const get = (req, res) => {
+  if (req.params.id) {
+    return res.json(await getPerson(id));
+  }
+  if (req.query.name) {
+    return res.json(await getPeopleWithName(req.query.name));
+  }
+  res
+    .status(404)
+    .json({ error: 'Please specify an id or provide a name filter' });
+};
+```
 
 ### Whare are the tradeoffs that PureORM makes in using SQL instead of a query builder API?
 
 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 DAO methods, since strings aren't as composable as stateful ORM builder builder APIs?
+### Will I then have dozens of similar DAL 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. There are [two ways](#ways-of-using-pureorm) to use PureORM. One abstracts over the database driver for convenience, but the datebase driver is always available to you (at `this.db`) if you wish to use it directly with no PureORM mappings. The other way of using PureORM doesn't abstract over the database driver at all (using PureORM to map the results is "opt-in") and the database driver is thus always used 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 DAL use the database driver directly.
+
+The only difference is how the SQL is invoked: `orm.one(query, {})` vs `orm.db.one(query, {})`
 
 ### Can I use aggregate functions while still using the PureORM mapping?
 
 Yes, if you'd like to get the mapping while also passing through some select expressions, use the special meta prefix. For example:
 
 ```javascript
-getBloggerPayout({id, startDate, endDate}) {
+const getBloggerPayout = ({ id, startDate, endDate }) => {
   const query = `
     SELECT
       ${Person.getSQLSelectClause()},
@@ -522,8 +497,8 @@ getBloggerPayout({id, startDate, endDate}) {
       person.pay_frequency
     ORDER BY meta_amount DESC NULLS LAST;
   `;
-  return this.one(query, { id, startDate, endDate });
-}
+  return orm.one(query, { id, startDate, endDate });
+};
 ```
 
 ## Comparisons
@@ -545,13 +520,11 @@ PureORM
 
 ## API
 
-### Classes
+### Interfaces
 
-#### `BaseBo`
+#### `PureORMEntity`
 
-An abstract class which is the base class your BO classes to extend.
-
-**Abstract Methods** to be implemented
+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:
@@ -562,51 +535,30 @@ An abstract class which is the base class your BO classes to extend.
     - `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)
 
-Optional
-
-- `get BoCollection(): BoCollection` - Returns the business object collection class constructor.
-- `static get displayName(): string` - Returns the string display name of the business object (defaults to camelcase of tableName)
-
-**Public Methods**
-
-- `createOneFromDatabase(relationalResultRows)` - Returns the properly structured Bo object (asserts one).
-- `createOneOrNoneFromDatabase(relationalResultRows)` - Returns the properly structured Bo object if results (asserts one or none).
-- `createManyFromDatabase(relationalResultRows)` - Returns the properly structured Bo objects (asserts many).
-- `createFromDatabase(relationalResultRows)` - Returns any properly structured Bo objects (no assertion on count).
-
-(Note these create from database methods ensure their count against the number of generated top level business objects - not the number of relational rows used!)
-
-#### `BaseBoCollection`
+#### `PureORMCollection`
 
 An abstract class which is the base class your Bo Collection classes extend.
 
-**Abstract Methods** to be implemented
-
 - `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")
 
-Optional
-
-- `get displayName(): BO` - Returns the string display name of the business object collection (defaults to bo displayName with an "s")
-
-**Public Methods**
-
-- `filter(predicate)`
-- and some advanced methods
+#### `create`
 
-#### `BaseDAO`
+The factory function for creating your ORM.
 
-The base class your DAO classes extend.
-
-**Abstract Methods** to be implemented
+**Parameters**
 
-- `get Bo(): BO` - Returns the business object class constructor.
+- `getBusinessObjects: () => Array<BusinessObject>` - A function which returns an array of all the business objects.
+- `db: <DataBaseDriverInstance>` - A database driver instance.
 
-**Public Methods**
+**Return Value**
 
-- `constructor({ db }})`
+Your ORM.
 
-Abstractions over `pg-promise`'s query methods:
+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.
@@ -614,9 +566,9 @@ Abstractions over `pg-promise`'s query methods:
 - `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 create from database 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.)
+(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 functions which your extending DAO class instance gets for free
+Built-in "basic" / generic crud functions
 
 - `getMatching(bo: BaseBO)`
 - `getOneOrNoneMatching(bo: BaseBO)`
@@ -627,38 +579,13 @@ Built-in "basic" / generic functions which your extending DAO class instance get
 - `delete(bo: BaseBO)`
 - `deleteMatching(bo: BaseBO)`
 
-These are just provided because they are so common and straight-forward. However, the point of this library specifically contrasts against having a large surface area of pre-built functions to learn. The idea is to add a DAO class, and add your own custom functions with your own SQL.
-
-### Methods
-
-#### `createBaseBO({ getBusinessObjects }): BaseBo`
-
-**Parameters**
-
-- `getBusinessObjects: () => Array<BusinessObject>` - A function which returns an array of all the business objects. In order for a business model to properly structure/nest data which could include any other business object, each business object needs to know about every other business object. We accomplish this by accepting this function which returns an array of all the business objects. (There is of course a circular dependency with the base class needing all classes that will end up extending it, but using this function handles this gracefully).
-
-**Return Value**
-
-- The BaseBo class to extend for your business objects.
-
-#### `createBaseDAO({ db, logError }): BaseDAO`
-
-**Parameters**
-
-- `logError: function`
-- `db: (database driver)`
-
-**Return Value**
-
-- The BaseDAO class to extend for your dao classes.
+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!)
 
-- `pg-promise`/`node-postgres` is the only database driver supported out-of-the-box for the integrated DAO usage path. There is not technical reason for this, other than that the project I'm using has a postgres database and so I only had `pg-promise` in mind. We could support more database drivers out of the box.
-- the dao you are writing your sql in must always be in the "select" and must be the one you want as your root(s) return objects
-  - the query can start from some other table, and join a bunch of times to get there, though
+- `pg-promise`/`node-postgres` is the only database driver supported out-of-the-box. There is not technical reason for this, other than that the project I'm using has a postgres database and so I only had `pg-promise` in mind. We could support more database drivers out of the box.
 - there must be a clear path in the "select" to your leaf joined-to-entities (eg, (Good): Article, ArticleTag, Tag, TagModerator, Moderator; not (Bad): Article, Moderator).
 - the result of _the select_ must always be a non-circular tree (eg, (Bad): Article, Person, Group, GroupArticle, Article)
 

package/examples/basic/bo/person.js

@@ -1,6 +1,7 @@
-const BaseBo = require('./base');
-
-class Person extends BaseBo {
+class Person {
+  constructor(props) {
+    Object.assign(this, props);
+  }
   static get tableName() {
     return 'person';
   }