data-store.md

 ## Abstract CRUD class
-We've made an abstract data model class, which individual models extend. Hopefully, this allows for easier data service replacement, if need be. Right now, the template implements JSData for data needs, which has additional explanation below. Here are the abstract class methods:
+We've made an abstract data model class, which individual models extend. Hopefully, this allows for easier data service replacement, if need be. Right now, the template implements JSData v2.x ~~v3.x~~ for data needs, which has additional explanation below. Here are the abstract class methods:
 * `create`: for POSTing one record at a time. (implements jsdata create method); ARGS: (attrs [, options])
 * `read`: for GETing one record at a time. (implements jsdata find method); ARGS: (id [, options])
 * `readList`: for GETing a list of the first page of records of a model. (implements jsdata findAll method); ARGS: ([params] [, options])
@@ -8,23 +8,22 @@ We've made an abstract data model class, which individual models extend. Hopeful
 * `destroy`: for DELETEing one record at a time. (implements jsdata destroy method); ARGS: (id)
 
 So, if you look at the configuration of the UserService, it extends AbscractModelService. And in a component, we inject it into the constructor as `User: UserService`, and go to town like so: `this.User.read(id).then()`    
-Note: previous versions of JSData used the `bypassCache` jsdata option, but in v3 it is now `force`
+~~Note: previous versions of JSData used the `bypassCache` jsdata option, but in v3 it is now `force`~~
 
 
 ## JSData & Models (Mappers)
-* the DataStore is set up in one single place, `.../service/store.ts`, and only that place
-* look to `.../models/User.model.ts` as a model for model setup
-* models import that store and interact with it to defineMapper or in the case of the abstract model, invoke methods on the store
-* we make the empty class, which extends `Record` so that we get useful class names for records like `User` or `[User, User, User]` in the console
-* _name_: this is how JSData keeps track of mappers internally, so that relations can be hooked up, etc. It would be nice if the class name could just use this name property, but alas the library does not seem to be written that way
+* the DataStore is set up in one single place, `src/app/shared/services/store.ts`, and only that place
+* look to `src/app/shared/models/User.model.ts` as a model for model setup
+* models import that store and interact with it to ~~defineMapper~~ defineResource or in the case of the abstract model, invoke methods on the store
+* ~~we make the empty class, which extends `Record` so that we get useful class names for records like `User` or `[User, User, User]` in the console~~
+* _name_: this is how JSData keeps track of mappers internally, so that relations can be hooked up, etc. ~~It would be nice if the class name could just use this name property, but alas the library does not seem to be written that way~~
 * _endpoint_: the REST endpoint this model will use when we run CRUD operations
-* loadRelations: in v3, you have to specify relations to load by the localField name, e.g. ` foo.loadrealations(['barObj'])`; loadRelations is a method available on an individual resource. See example below
-* pagination: where it at? how it do?
+* ~~loadRelations: in v3, you have to specify relations to load by the localField name, e.g. ` foo.loadrealations(['barObj'])`; loadRelations is a method available on an individual resource. See example below~~
 
 * _NOTE_: in an earlier version of this template, the CRUD methods took theJSData promise which resulted from the various methods employed and wrapped it in an Observable, in an attempt to follow the use of RxJS elsewhere in ng2. While this might serve a cool purpose on certain apps (merging streams coming from various sources for use in... something cool), that can definitely be implemented on a case by case basis, and we'll leave the promises alone for now.
 
 
-#### JSData Relations Example, using JSData v3, JSDataHttpAdapter v3
+#### JSData Relations Example, using JSData v2 ~~v3~~, JSDataHttpAdapter v2 ~~v3~~
 ##### Django Model
 ```python
 class Book (models.Model):
@@ -34,12 +33,13 @@ class Book (models.Model):
 ```
 ##### JavaScript JSData config
 ```javascript
-DataStore.defineMapper(name, {  // 'Book'
-  // ... endpoint, etc
+DataStore.defineResource({
+  name: 'Book',
+  endpoint: 'books',
   relations: {
-    belongsTo: {
+    hasOne: {
       Publisher: {
-        foreignKey: 'publisher',
+        localKey: 'publisher',
         localField: 'publisherObj',
       },
     },
@@ -51,34 +51,8 @@ DataStore.defineMapper(name, {  // 'Book'
     },
   },
 });
-
-DataStore.defineMapper(name, {  // 'Author'
-  // ... endpoint, etc
-  relations: {
-    hasMany: {
-      Book: {
-        foreignKeys: 'authors',
-        localField: 'books',
-      }
-    }
-  },
-});
-
-DataStore.defineMapper(name, {  // 'Publisher'
-  // ... endpoint, etc
-  // This relationship to Book is only necessary if you want Publishers to have the 'books' array (which 
-  // gets its name from localField), listing all books they are related to. But 'publisherObj' can still be 
-  // loaded onto a Book even without this side of the relationship defined.
-  relations: {
-    hasMany: {
-      Book: {
-        foreignKey: 'publisher',
-        localField: 'books',
-      }
-    }
-  },
-});
-
+  
+  
 this.Book.readList().then(books => {
 
   // loadedBooks === [
@@ -92,7 +66,7 @@ this.Book.readList().then(books => {
   //   }
   // ]
 
-  let bookPromises = books.map((book: any) => book.loadRelations(['publisherObj', 'authorObjs']));
+  let bookPromises = books.map((book: any) => book.DSLoadRelations());
   Promise.all(bookPromises).then(loadedBooks => {
 
     // loadedBooks === [