paperhive / octonom Goto Github PK

We still need an elegant way to resolve collections. Directly importing them will lead to cyclic dependencies and this i the road to hell. ;)

Version 5.0.1 of mocha was just published.

This version is covered by your current version range and after updating it in your project the build failed.

mocha is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Hooks and sanitization are not run on nested objects of a model instance:

class Person extends Model {
  @Property({type: 'object', definition: {foo: {type: string}}})
  public obj: {foo: string};
}
const person = new Person({});
person.obj = {foo: 'bar'}; // OK, triggers hooks
person.obj.foo = 'baz'; // NOT OK, doesn't trigger hooks

A model should have hooks for events like beforeSet, afterSet, beforeSave, afterSave, ...

Version 5.0.1 of @types/sinon was just published.

This version is covered by your current version range and after updating it in your project the build failed.

@types/sinon is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Mixins could do the job of defining and updating fields like createdAt or updatedAt. Example:

class PersonBase extends Model<PersonBase> {
  @Model.Property({type: 'string'})
  public name: string;
}

export const Person = Timestamp(PersonBase);

const person = new Person({name: 'Rosa Luxemburg'});

// the following should print the current timestamp
console.log(person.createdAt);
console.log(person.updatedAt);

A mixin of the following form works but the constructor's data argument has a wrong type then:

export type Constructor<T = {}> = new (...args: any[]) => T;
export function Timestamp<TBase extends Constructor>(base: TBase) {
  const newClass = class extends base {
    public createdAt: Date;

    constructor(...args: any[]) {
      super(...args);

      const date = new Date();
      if (!this.createdAt) {
        this.createdAt = date;
      }
    }
  };

  // ideally we'd use the decorator on the property as usual but
  // typescript doesn't like this yet, see
  // https://github.com/Microsoft/TypeScript/issues/7342
  Model.Property({type: 'date'})(newClass.prototype, 'createdAt');

  return newClass;
}

Instead of deriving from Timestamp we could have a CreatedAt and UpdatedAt schemas that can be used like this:

@CreatedAt()
public createdAt: Date;

This allows users to use their own property names which is not possible with the current Timstamp class approach.

Version 5.2.1 of @types/mocha was just published.

This version is covered by your current version range and after updating it in your project the build failed.

@types/mocha is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

We need tests that verify that 2 derived classes (from a base model class) get separate static properties (schema, hooks).

Instead of using interfaces for schemas we can make Octonom much more extensible by creating a base class SchemaValue or PropertyValue and derive classes like String, Array, Model, ... from it. The class should implement all we need (sanitize, validate). Users can then easily create their own classes.

Version 4.0.7 of @types/chai was just published.

This version is covered by your current version range and after updating it in your project the build failed.

@types/chai is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Setting them to undefined works as expected.

Version 2.2.48 of @types/mocha was just published.

This version is covered by your current version range and after updating it in your project the build failed.

@types/mocha is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Currently one has to explicitly specify the generic parameter for ArrayCollection and ModelArray (and possibly others), e.g. new ArrayCollection<Person>(Person) instead of new ArrayCollection(Person). Otherwise the type is a generic ArrayCollection<Model>.

Version 4.2.3 of sinon was just published.

This version is covered by your current version range and after updating it in your project the build failed.

sinon is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

MongoDB

• mongoose
• mongorito
• camo
• robe
• iridium

Couchbase

• ottoman

Multi DB

• caminte
• thinodium

Version 7.1.0 of chai-as-promised just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As chai-as-promised is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Example:

import { Model, Property } from 'octonom';
import { Timestamp } from 'octonom-timestamp';

class Child extends Model {}

class Parent extends Timestamp(Model) {
  @Property.Model({required: true, model: Child})
  public child: Child;
}

const parent = new Parent(); // stack overflow

The conditions in setObject() for resetting values should be checked. Also the default value logic should be checked.

We lose the type safety on the data parameter in model constructors if the derived class does not implement a constructor à la

class Person extends Model {
  constructor(data?: Partial<Person>) {
    super(data);
  }
}

Try to make the data parameter typed! Waiting for microsoft/TypeScript#5863.

Version 4.1.6 of sinon was just published.

This version is covered by your current version range and after updating it in your project the build failed.

sinon is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

For some data it would be nice if you can provide a sanitize function. Example:

@Property.String({sanitize: value => value.toLowerCase().trim()})
public email: string;

• depending packages should also get the @types of octonom when they run npm install
• add description
• add repository
• use prepare instead of prepublish

Version 5.1.0 of sinon was just published.

This version is covered by your current version range and after updating it in your project the build failed.

sinon is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

A REST API could be used as a collection! Yey @andywer!

Revert #66 when mongodb driver supports MongoDB 3.6.

Version 2.3.7 of @types/sinon was just published.

This version is covered by your current version range and after updating it in your project the build failed.

@types/sinon is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Version 4.0.9 of @types/chai was just published.

This version is covered by your current version range and after updating it in your project the build failed.

@types/chai is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Version 4.1.3 of sinon was just published.

This version is covered by your current version range and after updating it in your project the build failed.

sinon is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

A subtle issue you can find in most ORMs today is that you mutate model instances as you go and sync them with the remote database from time to time. It seems like an easy and convenient approach, but falls short if a model instance is used concurrently (esp. dangerous in JS with async code everywhere!).

Consider this:

const user = await User.findByName('Karl')
await Promise.all([
  renameUser(user, 'John'),
  changeBirthday(user, '1990-08-01')
])

async function renameUser (user, newName) {
  await something()
  user.name = newName
}

async function changeBirthday (user, birthday) {
  await somethingElse()
  user.birthday = birthday
  console.log(`User ${user.name}'s birthday is the ${birthday}.`)
  // Race Condition! Maybe `user.name` is still 'Karl', maybe it is already 'John'!
}

You can easily spend an hour of debugging to recognize the issue. And fixing it may be even harder.
So I'd like to propose a different approach:

const user = await User.findByName('Karl')
await renameUser(user, 'John')

async function renameUser (user, newName) {
  await something()
  // Returns an updated user instance, the old instance remains untouched
  user = user.setName(newName)
}

The setter methods could probably be easily derived from the field name. You could also track the change operations (setName, setBirthday, ...) since the last database sync and have a change history. Might be nice for debugging and to only update fields in the database that have actually changed.