Add options to pass to Neuro function called belongsTo, hasOne, hasMany, hasManyThrough

• Every relationship has a property on the model to which it's stored on.
• Options should be available to either store the object or it's ID in the property.
• belongsTo and hasOne refers to a single item where hasMany and hasManyThrough is an array. - Options should be available to send or not send the property the rest/live services.
• Options should be available to load models from rest/live services.
• belongsTo has a key on the current model that points to another model. The other model may have a hasMany relationship back.
• hasOne has a key on the current model that points to another model. The other model most likely doesn't have a hasMany relationship back because it typically doesn't know who it belongs to. When a relationship is removed from the model the related model is permanently deleted. A cascade = false option can be specified to override this functionality.
• hasMany has a key on the related model - so when a relationship is removed from the model the related model is permanently deleted. A cascade = false option can be specified to override this functionality.
• belongsTo has an option to add a discriminator column and map of Model types based on the discriminated value.
• When a model is removed that has belongsTo relationships, clear the property on the related model.
• When a model is removed that has hasOne relationship & cascade !== false, remove the related model.
• When a model is removed that has a hasMany relationship & cascade !== false, remove all related models.
• When a model is removed that has a hasManyThrough relationship, remove all related relation models.

Implementation

Add a NeuroRelationship class which provides the following functions (names pending):

{
  init: function(model, database, options) {},
  relate: function(model or key) {},
  unrelate: function(model or key) {},
  set: function(models or keys) {},
  save: function(model)
}

A version is stored in the database - each migration is tied to a version - up to the current version. When data is loaded locally and its version is less than the current version - each model is ran through the migration before being handed over the database to be "loaded".

• hasOne: If related is new, wait until it's done saving before saving the model
• hasMany: If model is new, wait until model is done saving before saving related
• hasManyThrough: If model is new, wait until model is done saving before saving through

A subset of all models in a database given some condition.

Features

• When models are ninja-saved they are re-evaluated by the query condition, if it's no longer a match for the query then it's removed.
• When models are ninja-removed, they are removed from the query.
• When the model-added event is triggered on the database, that new model is looked at and potentially added to the query.
• A query can have a comparator (and comparatorNullsFirst)
• Query will have the following methods: min, max, sum, avg, first, last, count. Each of the methods can accept a property name to pull a value from or a function which takes a model and returns a number. The count method doesn't need an argument, it will simply return the number of objects in the query.
• Query can have a subquery. A subquery watches for events on a query and runs an additional query check for inclusion.
• A query can have the option live: false which means it doesn't listen on model or database events. This is useful for temporary queries.
• A query's where parameter can be a function or an object where the models in the query must match the where object. (a createWhere function will be added similar to createComparator)
• Query will have a remove method which can remove all models in the query OR if a function is given all models in the query which return a truhy value when passed to the function.
• Query will have an update method which takes a set of new values to be applied to all models in the query. Optionally an additional filtering function can be passed.
• Query will have a groupBy method which takes a property or an array of properties AND an aggregation definition and generates an array of grouped values. The aggregation definition has fields as keys and the type of aggregation as the value (min, max, avg, sum, first, last, count). A third argument can be specified which is a function to use to further filter down the models that are looked at when grouped (having). The resulting array will have a $count variable which is the number of models grouped into that row and can optionally have a $group variable which is an array of all of those models (if a fourth property is specified). Maybe something like this instead?

query.group({
  by: ['user_id', 'done'],
  select: { cost: 'sum' },
  where: function(model) {},
  having: function(result) {},
  comparator: '-cost',
  accumulate: true
}); // = [{user_id: 3, done: true, cost: 456}, {user_id: 3, done: false, cost: 123}]

Ideally, Query should be used as the core storage of models over NeuroMap for NeuroDatabase & NeuroRelations so they can take advantage of all the sweet methods.

This is one big task!

Perhaps remote updates should not call checkSave in some instances? We shouldn't be loading related models and they cause a SAVE on the parent object.

This will allow collections to work seamlessly with libraries like Angular & VueJS which expect native arrays - and not objects that "extend" arrays. This does add a slight performance cost per instantiation, but it should happen less frequently. The current work-around for this libraries is to call .slice() on the collection which might be more costly - especially if that operation is done every update/scope cycle.

The user will need to define this behavior before Rekord is defined. Either through an attribute on the script which includes the library or through a short definition. For examples:

<script src="rekord.js" native-array></script>

OR

<script>var Rekord = {nativeArray: true}</script>
<script src="rekord.js"></script>

OR

<script>var RekordOptions = {nativeArray: true}</script>
<script src="rekord.js"></script>

• lazy options counteracts with the loadRelations option on NeuroDatabase
• query option is a templated string (using the fields of the object) URL to load an object/array of objects from to populate the relation. For example: /api/1.0/tasks/bylist/{task_list_id}
• Add RemoteQuery to accept a plain object for reset which will set the collection to a single model. This will allow single relationships to use the query option.

• Add possible where parameter to NeuroModelCollection.update.
• Add remove function to NeuroModelCollection which can optionally take where parameters.
• Add NeuroFilteredCollection which has a parent collection it listens to and an additional where function.
• Replace NeuroDatabase.models with NeuroModelCollection instead of NeuroMap.
• Add filter to NeuroCollection.
• Add subtract to NeuroCollection and NeuroModelCollection.

• Table per class hierarchy (parent has discriminator fields which decides it's type)
• Table per subclass (parent doesn't have table (no store/rest/live) but all models can exist)
• Parent table has discriminator option which points to a child table with extra fields to add to parent. Child table has parent option which points to the Parent.

Not sure the best way to implement this yet!

A model can be related to multiple models based on discriminating id & type.

nameOfMorph: {
  fields: 'parent_id', // field or fields that point to related object
  discriminator: 'parent_type', // field that determines the 
  mapping: { // a mapping from discriminator to the class
    'discriminator_value': DiscriminatedClass
  }
}

A model can reference a discriminated model

nameOfRelatedMorph: {
   model: ClassWithDiscriminator,
   morph: 'nameOfMorphInClassAbove',
}

Hey there!

I belong to an open source security research community, and a member (@yetingli) has found an issue, but doesn’t know the best way to disclose it.

If not a hassle, might you kindly add a SECURITY.md file with an email, or another contact method? GitHub recommends this best practice to ensure security issues are responsibly disclosed, and it would serve as a simple instruction for security researchers in the future.

Thank you for your consideration, and I look forward to hearing from you!

(cc @huntr-helper)

Bumps qs from 6.5.2 to 6.5.3.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps decode-uri-component from 0.2.0 to 0.2.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

The model is given an object/collection of objects from a remote source. Typically the parent model has the discriminator to know how to parse the input into a model. However sometimes you are given an object/collection that has its own ID and own type.

Person { contacts: [ { id: 1, type: 'phone' }, { id: 2, type: 'email ' } ] }

When a polymorphic relationship is being initialized and it comes to a given object to which there is and ID and discriminator on the parent object, if those properties were not parsed yet they are not detected and the model is not referenced.

• Set non-relations first in putRemoteData.
• Then set relations.

Rekord.addDecoder('boolean', {strict: Boolean}, function(value, params) {
  if ( params.strict ) ...
  return value;
});

var Model = Rekord({
  decodings: {
    property: 'boolean(strict:true)',
  }
});

You can also pipe one decoder/encoder to another.