Proposal for API changes

So I have been trying to think of ways that things could be improved. I've been using the library for about six months and I've hit many bugs and am aware of the weaker points of the API. Particularly the separation of concerns is problematic (especially when I was learning the interface).
I've never written any modern JS, but I've been trawling the docs after @tgriesser's example in #799. So I've taken the ideas I've had an think that they can be executed very effectively using the Babel toolset.
I've written up examples of how I think things could be implemented, and hopefully some of it resonates. Most of the changes are internal, so the API isn't drastically different.
Main things I want to address:
General separation of concerns
Query building and model state are too intertwined.
This, for instance, is very confusing to me: Model.forge({a: 'a', b: 'b'}).where(...).fetchAll(). I don't know what it does exactly, and would never write it, but I would prefer that it weren't possible.
Also, having state around queries seems wrong. The presence of resetQuery makes me uneasy that I might accidentally leave state in a model without realising it.
I would prefer very clear separation of concerns, where Model is a complex (but stateless) factory/resource management system, and model is a very lightweight model with no concept of queries, and no where.
So none of these are legal anymore in my proposal:
Model.forge().where(...)
new Model({id: 5}).fetchAll();
Model.forge({id: 4}).fetch();

Collections are not particularly useful
Pretty self explanatory and I think everyone agrees.
Queries are unexpected
Model.forge({id: 5}).someRelation().query() Gives a query that is only constrained to Model#tableName. This is confusing because you'd expect the library to be using query internally as you chain functions. It's also problematic (issues around count, and pagination, and just general flexibility.)
General refactor and modernization
The code is quite complex and would benefit from a refactor. Particularly in the relations area. In general I'd say that things are too stateful. There are also a few crufty abstractions like Sync that are very unclear how to use.
No nested saving, no bulk inserts.
Not even that hard a problem, unless I'm missing something. The main issue is that models are not aware of their relations. @tgriesser's suggestion of ES7 decorators comes in handy here. :smile:
Too much configuration
The options convention is really useful, but seems bloated in some areas. Better to split this behaviour out into different well defined methods.
Anyway, I'm waffling on because I'm about to post lots of code and I wanted to give it some context. Sorry for the immense read!

So, firstly, for some context, here is the readme example as I'd have it. Whenever you see a Model used explicity, it could just as easily be bookshelf('Model') in the style of the model registry. I've basically tried to make the interface look as much like Tim's example yesterday as possible.
import {Model, relation, table} from 'bookshelf';

@table('users')
User extends Model {
  @relation
  static messages() { return this.hasMany(Posts); }
});

@table('messages')
Posts extends Model {
  @relation
  static tags() { return this.belongsToMany(Tag); }
}

@table('tags')
Tag extends Model {}

User.where('id', 1).withRelated('posts.tags').fetch()
  .then(user => console.log(user.related('posts').toJSON())
  .catch(error => console.error(error));

The @table decorator exists to add the table name directly to the model constructor (ie. Tag.tableName === 'tags').

Now the main thing I wanted to achieve with this design is to divorce the concept of chains from the actual model state. Because I want all 'command builder' chains to come off the constructor, they absolutely must not store state. A mutable constructor function seems bad. (I'm calling them 'command builders' to distinguish them from knex's 'query builder'.)
So, I came up with this concept of a ChainFactory class. I don't know how different it is from how lodash, knex do chaining, tbh, but this is unique in that it copies the static interface of the Model it starts on.
I'll start from the bottom:
// -- ChainFactory

// ChainFactory generates command chains that inherit from its static interface.
// Any call to `chain` will either create a new chain, or continue an existing
// one.
//
// The rule here is that every chainable method calls `chain` internally
// to get an instance of "itself". This ensure that it will make sense when
// bound to the ChainFactory constructor, and also when it's intantiated. When
// instantiated `chainInstance.chain` is overridden to return itself.
//
// This obligation to call `.chain()` is hidden from consumers of Bookshelf, as
// they can make their own chaining functions by calling `.query()` or `.where()`
// as they can now.
class ChainFactory {
  static chain() {

    // Create new object with this constructor as its prototype. This will give
    // the `chain` the static properties Class.*
    let chain = Object.create(this);

    // Remove any static functions we don't want to chain. eg. `forge`.
    // We just override their name on the current object, shadowing the super
    // version.
    //
    // __notChainable is assigned by the `@doNotChain` decorator.
    for (property in this) {
      if (property.__notChainable) {
        chain[property] = null;
      }
    }

    // Now override the `prototype.chain` (ie. `ChainFactory.chain`), with a
    // function that returns itself. This way any chained calls
    // will not produce new instances.
    chain.chain = function () { return this; };

    // Allow state to be assigned here by inheriting classes.
    if (this.initializeChain) this.initializeChain(chain);

    // Return the new chain instance.
    return chain;
  }
}

// -- `@doNotChain` static method decoration

// Tacks on a little flag to methods that we don't want to reveal in chains.
//
//     class MyThingo extends ChainFactory {
//       @doNotChain
//       someStaticFunction() {
//         // ...
//       }
//     }
//
function doNotChain() {
  return function decorator(staticFunction, name, descriptor) {
    staticFunction.__notChainable = true;
  }
}

So, just say you have Model extends ChainFactory, the object returned from Model.chain() is a new instance whose prototype is Model itself (not Model.prototype, which is what you'd get from new Model()). This means that it inherits the static interface. Because there are static methods that don't make sense in a chain, you can decorate them with @doNotChain to tell the chain factory to hide them.
This doesn't make a lot of sense in isolation so I'll move on to Model now.

So, he is the (fairly large) Model class that I've concocted.
// -- Model, based on existing model, but different.

@staticAlias('q', 'query');
class Model extends ChainFactory {

  // Build a new model instance. Model.forge() is preferred.
  //
  //     Model.forge({id: 5});
  //     // same as
  //     new Model({id: 5});
  //
  // This is also overridden, however, to initiate a transacted save.
  //
  //     Model.transacting(trx).where(...
  //
  // is the same as:
  //
  //     Model(trx).where(...
  //
  constructor(attributes) {

    // No need to call `super` here, we're just inheriting static properties (amazing!).

    // Check if this is not being called as a constructor. Gives us the
    // transaction shorthand above.
    //
    // Much terser than `{transacting: trx}`, but still fairly clear in the
    // context of a transaction callback.
    if (arguments.callee !== this.constructor) {
      // If there are no arguments we return a command chain bound to a
      // transaction.
      let transaction = attributes;
      return this.transacting(transaction);
    }

    // Set initial attribute state.
    this.attributes = new Map();
    this.set(attributes);

    // Call overridden initializer.
    if (this.initialize) this.initialize();
  }

  get id() {
    if (Array.isArray(idAttribute)) {
      return idAttributes.map(attr => this.attributes[attr]);
    }
    return this.attributes[idAttribute];
  }

  isNew() {
    return _.isEmpty(this.id);
  }

  // Classic attribute mutator.
  set(attributeName, value) {
    _.isString(attributeName) {
      this.attributes.set(attributeName, value);
    } else {
      let attributes = attributeName;
      Object.keys(attributes).forEach((key) =>
        this.attributes.set(key, attributes[key])
      );
    }
  }

  // Classic attribute accessor.
  get(key) {
    return this.attributes.get(key);
  }

  // A few passthroughs here, for convenience.
  load(related, {transacting}) {
    return this.constructor(transacting).withRelated(related).load(this);
  }
  save({withRelated, transacting}) {
    if (this.isNew()) {
      this.create.apply(this, arguments);
    } else {
      this.patch.apply(this, arguments);
    }
  }
  patch({withRelated, transacting}) {
    return this.constructor(transacting).withRelated(related).patch(this);
  }
  create({withRelated, transacting}) {
    return this.constructor(transacting).withRelated(related).create(this);
  }

  // `refresh` replaces `fetch`. `fetch` only exists to terminate chains. You
  // can only `refresh` models. (I kind of prefer `renew` here because it sounds
  // like re-borrowing a book from a library. Thematic heh.)
  refresh({transacting}) {
    let attributes = this.isNew()
      :  this.attributes
      ?  _.pick(this.attributes, this.idAttribute);

    return this.constructor(transacting).where(attributes).fetch()
  }

  // -- Static non-chained members --

  // Model.load(engine, 'carriages')
  // // or...
  // Model.load(users, 'accounts', 'messages')
  //
  // Doesn't support nested loading.
  @doNotChain;
  static load(target, ...related) {

    // Accept array input.
    if (_.isArray(related[0])) related = related[0];

    // Bulk load each relation type.
    return Promise.all(related.map(relation => {
      let def = getRelationDefinition(relation);
      return def.attach(target);
    });
  }

  @doNotChain;
  static forge(attributes) {
    return new this(attributes);
  }

  // -- Chain members --

  // Intialize the chain instance.
  @doNotChain;
  static initializeChain(chain) {

    // `this` here is the constructor, as it's a static function.  Note,
    // `tableName` is attached statically to the class constructor.
    chain._ModelConstructor = this;
    chain._queryBuilder = knex(this.tableName);
    chain._withRelated = new Set();
    chain._returnSingle = true;
    chain._columns = undefined;
    chain._where = new Map();
  }

  // Set this chain to return all rows when `fetch` is called.
  static all() {
    let chain = this.chain();
    chain._returnSingle = false;
    return chain;
  }

  // Set this chain to return a single row when `fetch` is called.
  static one() {
    let chain = this.chain();
    chain._returnSingle = true;
    return chain;
  }

  // Add relations to be retrieved with the query.
  // Could just be called `with`.
  //
  //   House.where({id: 5}).with([rooms, occupants]).fetch();
  //
  static withRelated(relations) {
    let chain = this.chain()
    relations = Array.isArray(relations) ? relations : [relations];
    relations.forEach(relation =>
      chain._withRelated.add(relation);
    );
    return chain;
  }

  // How about using the following instead of the `object` syntax?
  //
  //     Model.q('where', 'id', '<', 10).q('where', 'id', >, 2).all().fetch().then(//...
  //
  static query(method, ...args) {
    let chain = this.chain();
    let query = chain._queryBuilder;

    // Handle 'whereIn', 'id', [0,2,3] type syntax.
    if (_.isString(method) {
      query[method].apply(query, args)
      return chain;

    // Handle callback syntax.
    } else if (_.isFunction(method)) {
      method.call(query, query, knex);
      return chain;

    // Handle terminating chain when no arguments are passed.
    } else if (_.isUndefined(method)) {
      return query;

    // Tell user if they made a mistake.
    } else {
      throw new Error('unexpected argument');
    }
  }

  static limit(limit) {
    this.query('limit', limit);
  }

  static offset(offset) {
    this.query('offset', offset);
  }

  // Set the current transaction.
  // Actually would like to use this shortcut as well:
  //
  //     Model(transaction).where('id', 5)...
  //
  // This allows `Model(null)` too, so you can write functions that are
  // transaction agnostic.
  //
  static transacting(transaction) {
    if (transaction) {
      return this.query('transacting', transaction);
    }
    return this.chain();
  }

  // Just the hash argument here.
  static where(attributes) {

    // Do all the prefixing and formatting here so that the consumer doesn't
    // have to. Also helps with DRY in Relations.
    //
    let formatted = this.prefixKeys(_.mapKeys(attributes, this._formatKey));
    return this.query('where', formatted);
  }

  // `fetch`. Now you can't call it on instances (see `renew`. It terminates a
  // command chain and builds a query based on the state it accrued during its
  // lifespan.
  //
  static fetch() {

    let single  = this._returnSingle,
        columns = this._columns,
        related = this._withRelated,
        Model   = this._ModelConstructor;

    // Now construct query. We just discarded the last reference to the chain
    // by not providing `query` with arguments.
    let qb = this.chain().query();

    if (single) qb.limit(1);

    // NOTE: `_this._columns` is `undefined` by default, so becomes '*'.
    return qb.select(columns)
      .get('rows')
      .map(record => Model.forge(_.mapKeys(record, this.parseKey))
      .then((models) => _ModelConstructor.load(models, related))
  }

  static relation(relationName) {

    // Ensure we have a relations object.
    let relations = this._relations || this._relations = {};

    // Do we already have a cached version of this relation?
    if (relations[relationName]) {

      // Yes, return it.
      return relations[relationName];
    } else if (this[relationName].__isRelation) {

      // No, but we can make one.
      return relations[relationName] = this[relationName]();

      // Friendly errors.
    } else if (this[relationName]) {
      throw new Error(`
        There is a static function called ${relationName}, but it has not
        been marked as a relation with the `@relation` attribute.
      `);
    }
    throw new Error(`Invalid relation name: ${relationName}`);
  }

  // -- Helpers.

  static parseKey(key) {
    return key;
  }

  static formatKey(key) {
    return key;
  }

  static prefixKeys(attributes) {
    return _.mapKeys(attributes, (value, key) => `${this.tableName}.key`)
  }
}

Okay, so now for some explanation...
So, the important thing to note is that Babel's extend performs not only the normal inheritance you'd expect...
class Child extends Parent { //...

// is equivalent to:
Child.prototype = Parent.prototype;
Child.__proto__ = Parent;

This means that every time you extend, you get to take your entire static interface with you. This is the first language I've been able to do this in, so pretty cool.
Chain has all the static functions of Model (besides the ones decorated with @doNotChain), but their this value is pointing at the chain instance instead of the static model. To make this work, both Model and chain need to conform to the same interface - they both have a method called chain(), but it behaves differently for each.
// creating a new chain: internally `where` calls `Model.chain` which is the chain factory method.
// These are two separate instances:
let chain1 = Model.where();
let chain2 = Model.where();

// However, because we inherit the static interface, they are easily modified by custom class definitions.
@table('songs');
class Song extends Model {
  static favourites() {
    return this.query('listen_count', '>', 100); // calls `chain` internally.
  }
}

@table('musicians');
class Music extends Model {
  @relation
  static songs() { return this.hasMany(Song); }
}

// Just works. (theoretically, ha)
Music.related('songs')
  .favourites()
  .whereIn('id', [0,1,2,3,4,5])
  .query('artist_name', 'ilike', 'devo')
  .query().count()
  .then(result => console.log('you learned: ', result));

So, something I noticed is true in the current code base, is that Relation is essentially immutable after construction. This means that I was safely able to copy it by reference when I was restoring Model#clone the other week. Of course nothing's really immutable in JS, but the API is currently designed so that you never interact directly with the Relation object.
So why bother instantiating these per object? You only need one per class. The basic idea is that the supplied relation definitions, eg
@relation
static function acquaintances { return this.hasMany(Acquaintance).through(Friend); }

...are considered to be factories for Relation models. (Much as they are now, but this time attached to the constructor instead of the instance, and only executed once).
The additional advantage of having these @relation attributes is that we can straight away know exactly which relations exist on a model, without any initialisation.
So, this makes these types of things much simpler:
let person = {
  name: 'Joe',
  friends: [
    {name: 'Tom'}, {name: 'Dick'}, {name: 'Harry'}
  ]
}

Person.withRelated('friends').save(person)
.then(joe => console.log('joe is friends with ', _.pluck(joe.toJSON().friends, 'name').join(', '));

This is how I do the same thing now:
var person = // as above
var friends = person.friends;
Person.forge(_.omit(person, _.isObject)).save().tap(function(person) {
  // Note constructing lots of Model instances here, would no longer be necessary.
  return person.related('friends').add(friends).invokeThen('save');
}).then(function (joe) {
  console.log('joe is friends with ', _.pluck(joe.toJSON().friends, 'name').join(', ');
});

Now Person already knows what relations a Person  can have. This also makes the options withRelated: true possible, which would just store all relations. You could have a model with 12 different relations and your code would not get any larger (unlike the last example which would almost double in size). But anyway, I'm going to put the final touches on my Relation classes and post them here.

But first I'll mention transactions.
This is my proposed API:
bookshelf.transaction(transacting => {

  // `withRelated()` without arguments defaults to saving all known relations.
  return Model(transacting).withRelated().save(data).then(model => { //...

  // Or we can do the equivalent from a `model` instance (the old way) like so:
  return Model.forge(data).save({withRelated: true, transacting}).then(model => { //...
});

Basically (shown in the massive Model definition above), the constructor is able to check if it's being called with new or not, and decide to return a chain with the query set to a transaction. This is purely for brevity.

It might be easier to create some of these as gists so we can discuss/update/fork with actual diffs, but a few notes:

https://github.com/tgriesser/bookshelf/issues/803#issuecomment-113018126 This has not accounted for actually making a connection anywhere. The idea behind the example I posted was that the connection to the underlying database is separated from any model definition.
Agreed, forge is going to go away entirely, I'm thinking that bookshelf(modelRef) will return a new model instance and static methods will go away for the most part, unless you want to use them for something custom but they won't be nearly as useful or necessary as they are now
The chaining isn't the difficult part, it's figuring out how to keep an efficient internal registry to be able to follow the unit of work pattern and deal with multiple objects mapping to the same row
Relations should be statically defined, and I'm thinking they should even be defined outside of the bookshelf layer entirely at a separate layer which is consumed/referenced by models - these can be decorated into custom relations via methods, but at the core the entire schema should be statically analyzable

I just pushed a branch next where I'm also sketching out some ideas for some apis / structure. Feel free to take a look

Okay, stuff to think about certainly. I'll have a look through your branch.

I must admit I'm not entirely clear on your meaning here. Do you mean connecting to the database? Or connecting models by a conceptual relationship? (btw, that was just the readme example with changed syntax)

Right, my main concern is not forge, but that model data and queries are all jammed into the one object abstraction, and they aren't necessarily related. Commands like where, select etc. I think that it's overloading the instance abstraction - hence why I went to the static interface.

I'll read up about it. The intention would be to automatically update multiple models for the same item on insert/update?

Yeah, that's a good idea. When you say 'the entire schema', do you just mean models and relations, or columns/types too?

Do you mean connecting to the database?

Yep, in your example:
User.where('id', 1).withRelated('posts.tags').fetch()

wouldn't work, because the User constructor doesn't have any knowledge of the db connection, that's why in my example you'd adapted from it'd be something like:
var db = Bookshelf(knex)
db(User).where('id', 1).withRelated(...

or
db('users').where(...

Yeah, that's a good idea. When you say 'the entire schema', do you just mean models and relations, or columns/types too?

Columns/types/potentially indexes as well, and while this info might not be required there's a whole lot more you can do / optimize (and less you'd need to type) when you know everything about the data layer looks like upfront, though I don't think this info should be defined on the model... it should be passed into the initialization of the Bookshelf/Knex libs.
In fact, you might not need™ to define "bookshelf models" unless you need to hook in for validation/serialization/instrumentation purposes, they could be created automatically based on the internal knowledge of the schema.
I'd also like to ensure there's appropriate helpers in knex to fetch the schema info from the DB so you don't need to write them all out by hand if you'd prefer the DB itself be the source of the schema.

...the User constructor doesn't have any knowledge of the db connection

Neither the constructor, not the models have a reference to knex attached. Model has knex in scope, and creates a new knex QueryBuilder whenever a constructor chain is called. (see Model#initializeChain above for specifics.) This is to simplify design around query state (since there is none attached to instances). And also why I suggested that asPartial might not be necessary, as the query only lives for the lifespan of the chain.
{Model} = Bookshelf(knex);

@table('users')
User extends Model { ... }

// `User` has no knowledge of connection/knex
User.where('id', 1).withRelated('posts.tags').fetch().then(user => //...
    |<-----        knex instance lifespan      ----->|

// `user` also doesn't have any knowledge of db or knex. It just knows it can
// call `super.save(this)` to save itself.

In fact, you might not need™ to define "bookshelf models"

Well, you may not need to, but generally I like to add methods to my models for use within my app. My models tend to have a lot of business logic or helper methods to them. eg. User.resetPassword() User.allowedAccessTo(resource). There would still need to be some way to define functions like this.
The kinds model extensions I use (as a consumer of Bookshelf 0.8) can be grouped into three categories: instance methods (set, get), static methods (forge), and chainable methods (query, any relation method, where).
What I would like to see is a clean, accessible way of defining and codifying those concepts and separating their APIs and state. But also allowing new models to be extended easily for use in application logic. The class syntax or Model.extend both seem like well understood conventions for defining objects, and I think the constructor chain thing is a nice way of encapsulating query state.
What I really don't want is model instances to have any knowledge of a connection, or a knex instance. Just to be simple data containers with get, set, attributes, and a few convenience methods:
  patch({withRelated, transacting}) {
    return this.constructor(transacting).withRelated(related).patch(this);
  }
  create({withRelated, transacting}) {
    return this.constructor(transacting).withRelated(related).create(this);
  }
// ...

Sorry if I'm banging on about this, I just want to make sure that you understand what I'm getting at. I feel as though I haven't fully grasped your vision presently.

Columns/types/potentially indexes as well

That's good to hear. I was under the impression that you didn't want that level of coupling between schema and ORM.
Ultimately, I'd probably prefer to tie the schema to the models, rather than read the schema from the DB. Then use a tool to generate knex migrations. That seems pretty far off at this stage though.

Model has knex in scope, and creates a new knex QueryBuilder whenever a constructor chain is called.

Yeah, this is what I'd like to get away from even further. Model should not be required to have knex in scope at construction time. You should be able to
import {Model} from 'bookshelf' // not bookshelf(knex)

class User extends Model {

  // ...

}

Well, you may not need to, but generally I like to add methods to my models for use within my app.

Yeah, for some, sure. I have an application with ~30ish tables and only about 4 of them need actual "business logic" methods defined... the rest of it is boilerplate that disappears when you know the schema.
And yeah, it'd basically mean that any static methods would just be defined directly on prototype

Ultimately, I'd probably prefer to tie the schema to the models, rather than read the schema from the DB. Then use a tool to generate knex migrations. That seems pretty far off at this stage though.

Yeah that's sort of the idea, that you could potentially do both.

Model should not be required to have knex in scope at construction time.

Right. The one advantage I can really see to this is the ability to break models into different modules without having to pass a bookshelf instance to them. Is that the idea? In my current project I've separated my models and bookshelf initialization into a separate module, but this means doing this:
# 'server' module
orm = require('models')(config)

MyModel = orm.model('MyModel')

# 'models' module
module.exports = (config) ->
  knex = require('knex')(config.knex)
  bookshelf = require('bookshelf')(knex)

  getFiles('./models').forEach (file) ->
    require(file)(bookshelf, config)

# ./models/*
module.exports (bookshelf) ->
  bookshelf.model 'ModelName', bookshelf.Model.extend {
    # ...
  }

It's kind annoying. It would be a lot cleaner if I could do this (which you appear to be suggesting):
# 'my-models' module
 module.exports {
  User = require('./models/user')
  Account = require('./models/account')
  #...
}

# ./models/*

bookshelf = require('bookshelf')

module.exports = bookshelf.Model.extend {
  # ...
}

# 'server' module
knex = knex(config)
bookshelf = bookshelf(knex)
bookshelf.registerModels(require('my-models'))

That said, all bookshelf() needs to do is this:
bookshelf = function(modelName) {
  Model = this.modelCache[modelName];

  // In my approach like this. In yours you'd extend the prototype.
  Model.createQueryBuilder = function() {
    return new knex(Model.tableName);
  }
}

bookshelf.registerModels = function(models) {
  let cache = bookshelf.modelCache;
  _.extend(cache, models);
}

So it's really not a very big change. In fact, I wonder how hard it would be to get a change like this going in master presently...

the rest of it is boilerplate that disappears when you know the schema.

I can certainly see the advantage to that approach. Implicit relations would be very cool, but they would still require names for use. For instance, table A could have two different has-many relations to table B, (ie. table B has two FK columns referencing table A). So this would be ambiguous:
# Just assuming that you'd use table names instead of model names when they're implicitly defined.
bookshelf('table_a').related('table_b').fetchAll()

Or perhaps that's fine to have as a kind of default setting, and you can upgrade to class definitions when you feel a concept is sufficiently complex, the above case being an example of that?

So it's really not a very big change. In fact, I wonder how hard it would be to get a change like this going in master presently...

It's a bit bigger than that, because there's a lot more that I'd like to accomplish with this change. Also mutating the model constructor like that sort of defeats the purpose, in mine you wouldn't extend the prototype, you'd instantiate a new Model passing the connection in the constructor.... no more using "new"
Also if you have multiple connections accessing the same models, you can't mutate them, you'd need to extend and cache

I can certainly see the advantage to that approach. Implicit relations would be very cool, but they would still require names for use. For instance, table A could have two different has-many relations to table B, (ie. table B has two FK columns referencing table A). So this would be ambiguous:

Presumably the relations would come with pre-defined names. Haven't fully determined the syntax.

Also if you have multiple connections accessing the same models, you can't mutate them, you'd need to extend and cache.

Right. I'm with you now.
I'll read through the next branch and keep iterating on this concept.

Presumably the relations would come with pre-defined names.

Thoughts on syntax:
You could generate names based on column names, using similar assumptions that Bookshelf uses currently. So, say there is a table called people, with two FKs to people called friend_id, and another called family_member_id, you could generate a model called Person, and relations called friends and familyMembers. (You'd need a good pluralization library for the people to Person conversion, but it would be cool.)
So, Person could be a 'default model', with no extra functionality. The model could be instantiated lazily (ie. first time you request Person model, it looks through the schema for a table called people).
If you've already called bookshelf.registerModel('Person', MyPersonModel) then it will extend the model with whatever extra functionality you like, on top of the default relations. If you don't follow the convention of relation_name_id you would be required to add your own relations here (or potentially use a more.  So, you get all the benefits of automatic relations, with flexibility to extend at the cost of more verbose code.
// entry point to program.
knex = require('knex')(/** config **/)
bookshelf = require('bookshelf')(knex);

// No definition required, bookshelf intuits (and caches) relation `friends` when it
// first initializes `Person` internally, via schema analysis.
bookshelf('Person').friends().where('name', 'ilike', 'Joe%').fetchAll()

// Now just say your 'friends' relation doesn't follow the required convention, you could do either of these:
{Model, HasMany} = bookshelf;

// cbf defining a model:
bookshelf('Person').addRelation(HasMany, 'friends', 'people', 'friendFK');
bookshelf('Person').friends().where('name', 'ilike', 'Joe%').fetchAll()

// or with a model (not necessarily using decorators and stuff, I'm not even sure
// if they're a good idea, but you get the point)
@tableName 'people'
Person extends Model {
  sayHello() {
    console.log(`Hello, ${@get('name')}!`);
  }

  // not sure if this attribute or static is necessary now, but via some method.
  @relation
  static friends() { return new HasMany(this, 'people', 'friendFK') };
}

// Register that model.
bookshelf.registerModel('Person', Person);

// Use original syntax. Only this time you get your decorated model.
bookshelf('Person').friends().where('name', 'ilike', 'Joe%').fetchAll()

// Can still access `familyMembers` because it *did* follow bookshelf conventions.
bookshelf('Person').familyMembers()...

I realized while writing this that only one side of the relationship has a foreign key though, so it's not going to be able to generate names via the column name for everything (in fact the above example a self-referential edge case, it would usually only work for belongsTo and belongsToMany relationships, I can rewrite it later). Most of the time the FK is just the name of the table, singularized with _id attached. You could default the relation names on the other side with the relation's model name.

Also, I'm sure you're aware of this, but having the models unaware of connections unify the transaction and normal syntax, which is really cool.
bookshelf('Model')...
bookshelf.transaction((transaction) {
  transaction('Model')...
});

But also another reason for not storing the queryBuilder in the model instance itself, as it might be tempting to take the model instance and use it outside of the transaction loop (which would not work). Perhaps the result of fetch should just be a simple object state (set, get, changed, etc.) without any save, load function at all, so you can do this:
bookshelf.transaction((t) {
  return t('MyModel').where(...).fetch()
    .then(m => t('MyModel').load(m, 'relationName')
    .then(m => // ...
}.then(modelObject => {
  // reusing model instance from trx, but it doesn't matter because all the connection info
  // is coming from `bookshelf.
  return bookshelf(`MyModel`).save(modelObject);
})

Hm... Certainly not as readable as model.save()...

Hey, after a comment on another issue I thought I'd raise my support for collections here rather confusing another thread...
First off I've only been using bookshelf for about 2-3 weeks so please tell me if I'm missing something. I do however come from a backbone background of about 2-3 years.
I find collections great for keeping models clean to handle instance specific tasks and collections great for handling multiple instance specific tasks.I don't have a collection for every model in my project, so I can see how they may be viewed as pointless in some applications but where I do have them I find them very useful.
At the moment I'm mostly using collections to load a group of models with a given query or a cache for model's I've already fetched and then retrieving them using collection.find rather than having to implement this manually using an array. And in some places I'm using other underscore methods like filter which again saves implementing it manually. But some collections also have helper methods on them which save me re-writing the code or confusing the model.
e.g. (if you need some context let me know)
getAccountToFetch : function () {
            //try to find the account we were last loading - it'll have a cursor that's not 0
            var current = this.find(function (model) {
                var cursor = model.get('cursor') || null;

                return (!_.isNull(cursor) && cursor !== '0');
            });

            //if we have one let's carry on
            if (current) {
                return current;
            }

            //otherwise get the account we refreshed the longest ago
            return this.min(function (model) {
                return model.get('lastFetched');
            });
        }

That said, collections aren't perfect, for example I would argue that the model.fetchAll method and collection.fetchOne are very confusing/pointless as model.fetchAll is just collection.fetch and collection.fetchOne is just model.fetch. And there's no way to save everything in a collection (that I can find) which means you end up having to do something like
 collection.each(function (model) {
          return model.save();
});

@rhys-vdw Is this conversation on-going somewhere? Is most of the work just being done on the next branch? I've made a big bet on a project replacing waterline in sailsjs with bookshelf. I'm excited about the next version and love some of the ideas being discussed here. I'd love to be able to know where to look to get an idea of what progress / changes are going into the next version.

Last public commit to next was June 17 (282abe55ea5070933b95858cd9415bd33887b558). I would also like to know if Bookshelf is under active development.

@kevinob11 @jordansexton Bookshelf is not currently under active development.

Id suggest objection - https://github.com/Vincit/objection.js/ It also plays nicley with es6 & 7.

@b3njamin not sure I'm ready to jump ship right away after a couple of weeks of integrating this with sailsjs, objection looks young, but does look pretty nice. @rhys-vdw bookshelf isn't going to be abandoned correct? What is current sentiment among maintainers?

@rhys-vdw Abandoned?

@arnold-almeida
Maintained by me and @rhys-vdw.

Hi @vellotis @rhys-vdw ! I'm wondering about the status of Bookshelf. I'm using it for a new project and I really like it. I saw some ongoing discussions (in 2015/2016) about the next version, and using ES6/7. Are there plans to continue development of Bookshelf or... should I consider moving to another ORM? 😟

@fcarreiro Bookshelf and Knex are stable, flexible, full featured, well tested, and used in production by many individuals and organizations. In addition, there are many plugins still being developed for it. By all means, consider Bookshelf (or any other ORMs you might evaluate) as you would any other library: on its merits.
You're essentially asking the library maintainers to project their expected effort in the future, and thus bear responsibility for your decision to use (or not use) Bookshelf now. As a counterpoint, if Bookshelf currently seems unmaintained/is missing features/doesn't use ES6/7, and that presents a problem for your use of it right away, what would really cause that perception to change?
Use Bookshelf, or "consider moving to another ORM" if you think that's best, but it seems to me that evaluating the historical and current development on the project per the commit history, Pulse, and Graphs on Github is a much better idea than deciding based on a reply to a comment on a 2 year old issue.
Per @rhys-vdw's comment above, Bookshelf isn't under active development. To me, that's not a huge problem, because of all the existing great things about it, but you can read the above thread and the look at the commit history to assess the state of the project.

Hi @jordansexton, thanks for the answer!
I have used Bookshelf, Sequelize and Waterline and also compared all the graphs you mention, and I ended up choosing Bookshelf. I think that it provides most of the things I need. My question was targeted at understanding if the current maintainers are planning to continue working on "new features/versions" or, for example, if they will mostly focus on bugfixes and minimal maintenance. In no way do I expect them to estimate their efforts nor do I expect them to choose an ORM for me.
What could represent a problem for me is the amount of unprocessed issues and pull requests. I wanted to know that if I was to find some problem and/or to propose a pull request, that it would be taken into account. Also, that the dependencies are regularly updated, etc. I don't expect the maintainers to do all the work (for free). I'd like to contribute myself but I've had the experience in other projects that sometimes no matter how much effort you do, the project stays stale.


DeprecationWarning: Tapable.plugin is deprecated

Webpack: v4.1.1
Happypack: v5.0.0-beta.1
Node: v8.1.3
Running my webpack build with the --trace-deprecation I see that the deprecation warning
(node:20108) DeprecationWarning: Tapable.plugin is deprecated. Use new API on `.hooks` instead

Is related to Happypack plugin
(node:20108) DeprecationWarning: Tapable.plugin is deprecated. Use new API on `.hooks` instead
    at HappyPlugin.apply (/Users/david.foxpowell/dev/sleep-spa-build/node_modules/happypack/lib/HappyPlugin.js:96:12)
    at webpack (/Users/david.foxpowell/dev/sleep-spa-build/node_modules/webpack/lib/webpack.js:37:12)
    at Promise (/Users/david.foxpowell/dev/sleep-spa-build/lib/tasks/webpack/index.js:23:26)
    at Promise (<anonymous>)
    at /Users/david.foxpowell/dev/sleep-spa-build/lib/tasks/webpack/index.js:20:12
    at Promise.resolve.then (/Users/david.foxpowell/dev/sleep-spa-build/lib/util/task.js:28:39)

same problem

looks like this is being tracked here https://github.com/amireh/happypack/issues/200#issuecomment-373699757


[Bug] Loadbalancer ignores scheduler ips

Rancher versions:
rancher/server: 1.6.2
rancher/agent: 1.2.2
Environment Template: (Cattle/Kubernetes/Swarm/Mesos)
Cattle
Steps to Reproduce:

Create a host with two dedicated ips
Setup a local service on the server on port 80 and bind to one of the ips
Add the host to rancher
Setup the host scheduler IP settings to use the other ip
Create a loadbalancer
Create a new entry on port 80
connect to both ips on port 80
you should only be able to connect to the rancher services

Results:
IP settings from the host scheduler ip settings are completely ignored and all traffic is being redirected to the loadbalancer which may break any other host setup.
Expected behavior
Use the scheduler ip settings if no other settings on the loadbalancer are specified.

I'm confirming this behavior after creating brand new hosts. This is basically making Rancher completely unusable for my installation.

Please let us know in a comment if you can still reproduce the issue, and we'll reopen it


Templater usage issue

Hello! Firstly let me say that this is awesome.
Secondly, I'm having an issue - I have this set up to be called as part of my daily note, using Templater as follows:
<%* app.commands.executeCommandById("weather-fetcher:weather-insert") %>
Edit - Actually it's inserting the weather at the cursor position, which is the top of the file, not the location in the file where the above template command is located.

I am having a similar issue with the Templater content being inserted into a random location in my file.

Same here. Would be nice of having some way of using it from a template

Same issue. Has someone a solutions to this?

Hello peeps! I think I have a solution for y'all :)
Due to the plugin looking at the cursor position for where to insert the weather info-- simply manipulate the cursor's position programmatically within the Templater snippet.
<%*
app.workspace.activeEditor.editor.setCursor(14, 1); // lineNumber, characterNumber
app.commands.executeCommandById("weather-fetcher:weather-insert")
%>

Note: In my tests, it appears that it is actually inserting on 2 lines before what I indicate in the setCursor() function. I'm not sure if it will be the same for others, but do a couple experiments to see how it works for you.


Support HTTPS proxies

This adds support for HTTPS proxy servers, which means an HTTP proxy that is capable of proxying TLS traffic to the remote endpoint. This addresses issue https://github.com/twitter/CocoaSPDY/issues/33.
It adds support for only a single proxy server in the configuration. A PAC file downloaded from an auto-configuration URL could theoretically returns multiple proxy servers, which are expected to be attempted in succession until a successful connection is made. This is not supported here, but could be added in the future. Much of the code is written in a way to support this, all that remains is the SPDYSocket "_close" codepath (should try next proxy).
Manual testing has been done in the simulator, using the Mac's system proxy settings and the Charles software, including induced failures to connect. More testing needs to be done on real devices against real proxy servers.

Plesase recover as soon as possible.As a Chinese user,we really need this!

Plesase recover,this is only way  access to Twitter easily.

Thank you so much


Fix "bad Redis" failure case flakiness

The previous implementation relied on failure due to a bad Redis host name. This worked most of the time, but while running the test suite in a coffee shop, this test case would timeout and leave a stale redis-server running in the background. Eventually I realized this was because the coffee shop DNS provider was converting failed name lookups to search queries.
This implementation instead relies on connecting to an unused port, and doesn't start a redis-server instance to begin with.
cc: @akashvbabu @mpdatx

Coverage remained the same at 98.065% when pulling d265004f41f1697c9db6c421a5caeae1cc6bc75e on fix-smoke-test-flakiness into 1b587f1208ae308599c7f94c0d9d24a039c7a5c0 on master.

Coverage remained the same at 98.065% when pulling d265004f41f1697c9db6c421a5caeae1cc6bc75e on fix-smoke-test-flakiness into 1b587f1208ae308599c7f94c0d9d24a039c7a5c0 on master.


Allow to select user when assigning an issue

Command -
jira i <issueId> -a <user>
Requirement -
It should allow to present the list of users matching user parameter as most of the time we don't know the exact user name. The list to be presented as selectable options.

I have created a Pull Request for the same. It is working perfectly fine for me. Kindly check and merge into master. PR  https://github.com/foxythemes/jira-cli/pull/51


Detect/report non reachable sensors

Homebridge-hue is not doing anything wrong, but I’m wondering is I have missed an option, setting or possibility.
I feel I’ve read about this, but can’t find it anywhere. Apologies if it has been asked before!
I have oodles of temperature sensors all over the place. (All Aqara or Mi.)
I only JUST noticed that a couple of them show as ‘Not Reachable’ in the Phoscon web app. If I understand correctly, in this state, deconz and/or homebridge-hue continue to report their last valid reading. That would make sense based on the readings I see in the Home app. (I thought I had some warm spots in some of my rooms, but I think it is just the last reading from a week or two ago! haha)
If I hadn’t gone into the Phoscon app, I wouldn’t have seen that those sensors were grayed out.
Is there a way to be alerted when a sensor has become non-reachable? Or has become non-reachable for longer than a certain amount of time? With lights, it’s kind of hard to miss when they’re non-reachable. But with sensors…
Or is someone aware of maybe an additional plug-in that can keep track of sensors and send an alert if it goes to a certain status or if it hasn’t had activity in longer than a certain amount of time?
Or am I just doing something totally wrong?

Homebridge Hue sets Status Fault when the gateway reports devices as non-reachable.  Unfortunately the Home app ignores this, but Eve shows an exclamation mark.
See also https://github.com/ebaauw/homebridge-hue/wiki/No-Response.

Are you aware of any kind of plugin or other app or service that can act as a watchdog and alert to a "Status Fault" situation perhaps? I could swear I remember reading about something like this, somewhere, many months ago, before I realized it might be useful. But I can't find anything now. It might have been a dream...

Status Fault can be used in HomeKit automations, just like any other numeric characteristic.  You just need to use a decent HomeKit app.  If you want a non-HomeKit approach, better use the deCONZ API to monitor reachable.
HomeKit only sends notifications for certain sensors, like smoke, motion, door/window.  See the Home Settings in the Home app.  You could create a CLIP sensor in deCONZ, set that based on the light state.reachable, using deCONZ rules and then expose this virtual sensor through Homebridge Hue.  I’m not sure if deCONZ have implemented a CLIP version for each sensor type, but CLIPOpenClose works.  I use that to get a notification if my washing machine has finished.  I’m triggering the virtual sensor from state.power of the Heiman smart plug (when trying this at home, make sure to use a smart plug that can handle 16A, unlike the innr).


"Enable NEAR_NEAR1MV compound mode" impacts default speed bdrate

Thomas told me 5f6345bbf6b53e36b6fad5ecf9862b1de175a8ad shouldn't have an impact on default speed levels. This is broken according to AWCY.
https://beta.arewecompressedyet.com/?job=master_30aad0e%402020-07-08T16%3A09%3A11.135Z&job=master_5f6345b%402020-07-08T15%3A59%3A13.962Z

This is because the patch caused the near speedlevel setting to be respected, which ended up disabling NEAR_NEAR0 on default speed. We could add a finer control to speed levels to bring it back.


I don't know how to open

which button should I click, what does copy the repo mean, pls add more information thankyou, I'm just trying to show my friends I can play games on the touch bar.
Thank you!!

"Repo" is short for repository. You'd need to clone the repository (or at the very least download its contents) if you wanted to compile the application from source code.
However, the README has a link to a zip file containing the app, so you can just download that.


Feat : lifecycle Meta-Argument with  Optional variables

Problem Statement :
Module is not restricting/ prompting  user before destroying or recreating
suggested solution:
we can include lifecycle Meta-Argument  with variables  as  optional parameters , so any user perform accidental delete or due to some external modules database won't recreate and help user in maintaining the data

similarly, it would be nice to ignore_changes on storage_mb when auto-grow is enabled.

Hi @skgandikota @robin-wayve , thanks for your request! Terraform meta-arguments only accept literal values; it would be tricky to do something as you suggested. Appreciate your contributions!


online tool: disk quota exceeded

Hi,
just as info: When I try to use the online tool I receive an error that says:
<type 'exceptions.IOError'>: [Errno 122] Disk quota exceeded
args = (122, 'Disk quota exceeded')
errno = 122
filename = None
message = ''
strerror = 'Disk quota exceeded'
Cheers,
Josephine

I found the same problem with the web version. Please advice. Thank you!

Hi Josepine,
Sorry for the inconvenience, we're currently in the process of migrating servers and some of our online tools (such as the MUSiCC web application) will be unavailable during this time.
I'll post an update once things are back online.

Hi,
I apologize for the long delay, but we have just finalized our server migration. You can now find the MUSiCC web application at http://elbo-spice.cs.tau.ac.il/MUSiCC/MUSiCC.cgi.
Please let me know if you run into any issues or have any questions!
Best,
Alex


Add a command to run/debug tests with the current filter from anywhere

Currently there is a way to run or debug all tests (commands testing.runAll or testing.debugAll), but it would be helpful if I could apply a filter to the Test Explorer and then still run those tests if I navigate back to the File Explorer.
The commands testing.runSelected and testing.debugSelected do run with the current filter applied but they only work if you have to Test Explorer open, so if I navigate away from the Test Explorer to say the File Explorer or the debugger view then I cannot re-run those tests.
The testing.*Selected commands both go through https://github.com/microsoft/vscode/blob/main/src/vs/workbench/contrib/testing/browser/testExplorerActions.ts#L261 which is currently tied to the TestingExplorerView.
One way this could work is to have the testing.*Selected commands accept a filter as a parameter but default to the filter loaded into the TestingExplorerView if specified, otherwise it could run all tests.
Let me know if that sounds reasonable and I could take a look at PR for that.

Possible workaround for now is to use "multi-command" extension: https://marketplace.visualstudio.com/items?itemName=ryuta46.multi-command


Steepest descent

Added steepest descent step size to IST and FISTA so that we don't need to use Lipschitz constant.
This is especially useful for non-Cartesian.
In some cases, it works even better than using the actual Lipschitz constant.
In a nutshell, let p be the descent direction at each iteration, then the step size is estimated as:
step = ||p||^2 / ||Ap||^2 and is guaranteed to converge.
I switched the order of thresholding and gradient update. Hence, this will affect the default behavior slightly.

Hi Frank, I will take a look at this.  I don't know what "steepest gradient step size" means. Is this the Cauchy step size? In this case, it would be better to call it like this. How about trying Barzilai and Borwein? Is there some reference for step sizes in IST/FISTA? Finally, to you free 'o'?

I guess it's Cauchy's stepsize, but it's called steepest descent in signal processing...
Daubechies' (second) paper is the only one that I've found so far:  http://people.ricam.oeaw.ac.at/m.fornasier/DFL07c.pdf
I've tried Sparsa before (http://www.lx.it.pt/~mtf/SpaRSA/), which uses Barzilai and Borwein step size for sparse problem. But it does back-tracking line-search, so it wasn't fast when I tried it. I think I freed 'o'

The paper from Daubechies et al. has a comment that this stepsize choice has been observed not to converge with soft-thresholding (in contrast to projected gradient), but maybe they didn't scale the thresholding parameter? So why is this guaranteed to converge? Also from looking at the implementation, I do not yet understand what you are doing here: You first compute the search direction by doing a gradient descent step with soft-thresholding as usual and then take the direction of this (non-linear procedure) as a new search direction for which to compute the step size according to the Cauchy step size for quadratic problems?

tau is inverted in each step?

I think I'll move the step size out as a separate function. But for now here's a note that tries to explain the function and prove that the IST with Cauchy step size does converge to the optimum:
ist_no_lipschitz.pdf

Fact 2 isn't a fact I would say. Also what is wrong with the following algorithm?
x_{n+1} = prox(x_n + \alpha p)   where  p = A^H(y - A x) and \alpha = |p|_2^2 / |Ap|_2^2
This would avoid doubling the number of operator applications.

Na, it wouldn't...


Fix generating types like float44 and float88

This fixes #5704 and #5710.
The existing tests already fail before this patch so I did not add any new tests.

Thanks @abergeron !


[Discussion]could I use lrange with pipline ?

hi,dear
when I run the down codes,I got the wrong thing,
>>> redis_obj=get_redis()
>>> with redis_obj.pipeline() as pipeline2:
...     key_feat=pipeline2.lrange('kdjdjo',0,100)
...
>>> key_feat
ClusterPipeline

So why is the ClusterPipeline ? it should be a list in fact
could you pls help me ?

@ucasiggcas You still open up an issue claiming it as a discussion. There is a separate tab for this in github, please use that and do not open up another discussion issue here as this is for issues and reportable problems/bugs.


elasticsearch7.x support

it support elasticsearch7.x ?

@myswhozxj id did a quick test with an elasticsearch 7 docker container. it seems to work. certainly it wil not yet support new features of es7, see #271 for example.

#271 was solved by #277 . The PR introduces fixture files for ES 7.3.0. The test results look good, but so far there is no mechanism to differentiate the ES versions in the code. I try to come up with a solution for that so we can start supporting features that are specific to the different ES versions

i test the export, it is ok. but when i collcet metrics, some metrics keys is missed.

Note: SoundCloud use this exporter successfully with Elasticsearch 7.5.2.

Couple of questions , hope @grobie if you can answer,

Do you run exporter on all ES nodes ?
Do you guys use the Grafana dashboard provided in this example? I see the names are wrong and it does not work for me.
Could you please share the Grafana dashboard and Prometheus conf?

Do you run exporter on all ES nodes ?

Yes

Do you guys use the Grafana dashboard provided in this example?

No, we use our own dashboards. Our dashboard includes some internal information and can't be easily shared unfortunately.

Do you run exporter on all ES nodes ?

Yes

Do you guys use the Grafana dashboard provided in this example?

No, we use our own dashboards. Our dashboard includes some internal information and can't be easily shared unfortunately.

Sure, I understand. Possible to share Prometheus.conf ?


add eps registers and home assitant json

Building on #239, adding registers for the EPS data and also updating the json for the Home Assistant integration.

This looks good, the only thing thats starting to fall behind is probably the database storage, but I'm not sure if anyone really cares.

Thanks for doing this! I have a new inverter setup and am figuring out how to balance the split phases. I saw on the web dashboard "EPS L1N" and "L2N" and was wondering how to get those in lxp-bridge. Then I saw this pull request :)

Unfortunately this PR seems to have broken lxp-bridge on my system. I'm not sure how to go about debugging it, but what happens is if I run this new build, the active EPS power stops being updated. If I revert back to the previous commit, it works. I'll try to collect more debug info, just an initial observation.

Unfortunately this PR seems to have broken lxp-bridge on my system. I'm not sure how to go about debugging it, but what happens is if I run this new build, the active EPS power stops being updated. If I revert back to the previous commit, it works. I'll try to collect more debug info, just an initial observation.

I'm addressing this in https://github.com/celsworth/lxp-bridge/pull/249


Storybook story source code isn't being genreated correctly

Steps to reproduce

Go to e.g. https://storybook.design-system.digital.mod.uk/?path=/docs/button-experimental--default
Click on the code button

The source code isn't generated correctly:

However, this is supposed to work: https://github.com/storybookjs/storybook/pull/11332
It can also be seen working in this example here:
https://next--storybookjs.netlify.app/official-storybook/?path=/docs/docs-source--loading
We need to investigate why it's not working in this project.

It looks like it's been turned off here: https://github.com/defencedigital/mod-uk-design-system/blob/master/packages/react-component-library/.storybook/preview.js#L35
So we just need to check if there's any reason for that and if it can be turned on safely.


Transaction Issues

I was able to successfully transfer BTS coins into the smartwallet. However, I do have several issues. Most importantly, I am not able to send, or transfer out. The scan code function, brings up the app to scan, but as it scans the barcode, the smartwallet app ceases to function. Secondly, when I intiate a transfer out using a service such as shapeshift, It does not recognize my BTS address, stating the address is invalid. However I used the same address to transfer in from Shapeshift. Lastly, when I go into contacts to add an address, the app auto changes my capital letters to lowercase thus changing the arrangement of the correct sending address and it becomes invalidated. All in all, I have BTS coins that cannot be used. Please advise on the remedies to solve the problems. Thank you for your time.

I have transfered 100bts to livecoin-net ..anyway in my wallet there s confirmed success..but to livecoin-net there s no find my 100 bts transfered.
Livecoin said that they cant not find the block of my transfer..
Can you help me?

Hell o..
I never got no answer from this site with my trouble..
I lost my 100 bts from my smartshare wallet in transfer to my live coin wallet..
I hope any responsible from the smartshare wallet developer..


How to set data of ref inside setup in vue3

I created a component using the setup in vue3, how can I update vue ref using vue-test-util 2?
import { defineComponent, ref } from "vue";
import { mount } from "@vue/test-utils";

const Nav = defineComponent({
  template: `

      My Profile
      Admin

  `,
  setup() {
    const admin = ref(false);

    return {
      admin,
    };
  },
});

const factory = () => {
  return mount(Nav);
};
describe("ConditionalRenderer", () => {
  test("renders a profile link", () => {
    const wrapper = factory();

    // Here we are implicitly asserting that the
    // element #profile exists.
    const profileLink = wrapper.get("#profile");

    expect(profileLink.text()).toEqual("My Profile");
  });
  test("does not render an admin link", () => {
    const wrapper = mount(Nav);

    // Using `wrapper.get` would throw and make the test fail.
    expect(wrapper.find("#admin").exists()).toBe(false);
  });

  test("renders an admin link", async () => {
    const wrapper = mount(Nav, {
      data() {
        return {
          admin: true,
        };
      },
    });
    // Again, by using `get()` we are implicitly asserting that
    // the element exists.
    expect(wrapper.get("#admin").text()).toEqual("Admin");
  });
});

Right now there is no way to update a ref inside setup. That said, it looks like there is no way for a user to update the value of admin from the component either - seems like you are attempting to test a case that is impossible in any real application.
You could make admin a prop or something, perhaps?

Currently no way to modify values in setup, so I'll close this. I don't expect this is something that will be implemented - if you need to update value, I'd recommend doing it like a user with trigger, props, etc.


Remove the Identifiable class from dsol

This class already exists in djutils, and the dsol version is not explicitly used.

Removal of Identifiable class done. As far as visible, there are no side effects in the dsol project.


Debug toolbar reposition buttons

This PR fixes #129039
Changes:

Repositioning debug buttons in the debug toolbar.
All the existing tests passed successfully, I don't think there is a need for adding specific test to this change as it's a simple re-order.

Thanks for this PR, however I will have to close it, since I prefer if we just change the weight of the reverse continue. And since I have to tackle this today I plan to push this myself. Sorry about that!

Hi there,
No worries at all, I understand.
Thanks for your guidance.
Best of luck : )


Require Mission ID in ODLC Requests

To identify the odlcs for a specific mission so that the server can support multiple simultaneous missions.

Add mission ID to API requests.
Store mission ID with the odlc in database.
Filter for odlcs by mission ID in the scoring.

Hi Phil,
I understand that we will need to provide Mission ID when posting ODLC to the server, will the Mission ID be required when posting Telemetry data also?
Thanks,
Justin, VAMUdeS

No. We can identify the telemetry for a mission by the TakeoffOrLandingEvents, which we can't do for ODLC (can be submitted while on the ground, can't reliably mark mission status due to judge availability). The remaining API changes are listed here.


dynamically manipulating choices

Hello there! does we have setChoices available on this component?
i tried like this:
this.inputEl.setChoices([                     {                         value: 'Four', label: 'Label Four'                     },                     {                         value: 'Five', label: 'Label Five'                     },                     {                         value: 'Six', label: 'Label Six'                     },                 ])
what i am about to acheive here is dynamically changing the options based on what choice user have.
so for instance:
            this.inputEl.addEventListener('addItem', function(event) {               if(event.detail.value === 'a'){                     // change the choices...                }             });
i would be glad to hear from u guys.
tnx in advance.

Hello @pouyamiralayi,
In the case you are setting the component with type="single"/type="multiple", you can use setChoices() method or just update choices property:
this.inputEl.choices = [
  { id: 0, value: 'superstar', label: 'Superstar', selected: false },
  { id: 1, value: 'adizero', label: 'adizero', selected: false },
  { id: 2, value: 'stansmith', label: 'Stan Smith', selected: true }
];

this.inputEl.setChoices([
  { id: 0, value: 'superstar', label: 'Superstar', selected: false },
  { id: 1, value: 'adizero', label: 'adizero', selected: false },
  { id: 2, value: 'stansmith', label: 'Stan Smith', selected: true }
], 'adidas-shoes', 'adidas shoes', false);

You can also see the main library setChoices() documentation.

thanks for your kind answer. i haven't noticed the type you just mentioned. i appreciate that.
tnx in advance.

You are welcome @pouyamiralayi!


[Pharmacy] System is not allowing to create prescription with past date

Actual Results
After filling all details of the prescription, setting a date before the date the patient was checked in and request to save the prescription, system shows following error message "A data e hora da consulta deve estar entre as datas de início e fim da visita"
Expected results
System should save the prescription.
Steps to reproduce
POC->Pharmacy->Type Celio on search patient -> Select Celio Antunes -> fill prescription details ("Data da Prescrição" must be any current date) ->click blue icon Adicionar -> On "Nova Prescição" click blue icon "Confirmar"
Screenshot/Attachment (Optional)

Fixed by PR https://github.com/esaude/openmrs-module-pharmacyapi/pull/40


[medToolBox]: add error for 3D and 4D meshes

@fcollot can you look at this small PR for @paulineMig ? It's needed to compile right now


Null safety

The starting point for sound null safety for the core application.
The code is growing permanently and since we will probably get external support soon it is probably good if we switch to null safety as soon as possible.
Here is an overview of what is already done:

lib

[x] bottom_sheet_views

[x] ...

[x] cards

[x] category_cards
[x] data_cards
[x] expandables
[x] product_cards

[ ] data_models

[ ] database

[x] functions

[x] lists

[ ] pages

[x] pantry
[x] product
[x] scan
[ ] ...

[ ] themes

[ ] views

[ ] ...

[ ] test

@monsieurtanuki  can you take over the data_models and database part? If you switch to this branch you should be able to get to the current level with dart migrate,
cf. https://dart.dev/null-safety/migration-guide

@M123-dev Done.

Thanks @monsieurtanuki, I have seen it, we have only one problem, because the changes were applied before all files were updated, some files are null safe and some are not, this caused that the migration tool would not start anymore.  We had many errors, I have fixed a large part but there are still many and it may be that not everything is solved exactly right

Hi @M123-dev!
Indeed I've switched directly to null safety. I never found the migration tool that relevant.
If you prefer feel free to ignore my commit.
Anyway, it's not going to be 100% right at the end; there's probably going to be some fine-tuning.

The most errors are fixed by now @monsieurtanuki, can you fix the remaining ones

Hi @M123-dev!
I "fixed" the code errors.
That doesn't mean that the app works at 100%, I need to go now and could not test a lot of features.
I saw two types of "invisible" bugs:

a late variable that is eventually not initialized, which causes a runtime crash
the TextFormField does not work the same, as beyond null safety other components changed with the new version of dart. For instance, I could not create a new list, because the "okay" button validation seems to work differently.

Thanks for the fixes @M123-dev, I could not reproduce the erros you mentioned but fixed a few others. Only two are now left (at least for me). I removed the nullable annotation so that they are mentioned in the analyzer.

When scanning a barcode
======== Exception caught by widgets library =======================================================
The following _CastError was thrown building:
Null check operator used on a null value

When the exception was thrown, this was the stack:
#0      ProductList.getProduct (package:smooth_app/data_models/product_list.dart:127:65)
#1      ContinuousScanModel.getProduct (package:smooth_app/data_models/continuous_scan_model.dart:86:60)
#2      _SmoothProductCarouselState._getWidget (package:smooth_app/lists/smooth_product_carousel.dart:72:56)
#3      _SmoothProductCarouselState.build.<anonymous closure> (package:smooth_app/lists/smooth_product_carousel.dart:56:16)
#4      CarouselSliderState.build.<anonymous closure> (package:carousel_slider/carousel_slider.dart:289:36)
...
====================================================================================================

In the choose_page categories an error is shown on screen because in dao_product_extra.dart  _getExtraKey and _getExtraReverse acceppted nullable id's, this is fixed but we mostly pass nullable id's, we have to check this before calling these functions.
An error occurred: Exeption: Unknown product list of type http/search/group

I've just fixed both cases:

In this case, the Product was retrieved from the product list, and then, according to a status, we do something. And we do something with the product only for some status, which are the only cases when we are sure to find the product in the list. The fix was to compute the product not "just in case", but only when we needed it.
_getExtraKey does need to accept null ids (some hard-coded lists like history or scan don't have ids). The problem was somewhere else (before putting items in a new product list, the list needs to be create in the db first)

I think we are done now, @monsieurtanuki aren't we

As far as we tested, we're done. We'll find the next possible bugs after the merge.


send all except kCommandSeverity and kAlwaysSeverity to stderr

Fixes #179

CI gfxreconstruct build queued with queue ID 20645.

CI gfxreconstruct build # 2128 running.

CI gfxreconstruct build queued with queue ID 20659.

CI gfxreconstruct build queued with queue ID 20660.

CI gfxreconstruct build queued with queue ID 20664.

CI gfxreconstruct build # 2129 running.

CI gfxreconstruct build # 2129 passed.

CI gfxreconstruct build queued with queue ID 25468.

CI gfxreconstruct build # 2160 running.

CI gfxreconstruct build # 2160 passed.

CI gfxreconstruct build queued with queue ID 26282.

CI gfxreconstruct build # 2166 running.

CI gfxreconstruct build # 2166 passed.


feat: add support for pin_write with type="file"

This PR adds support for pin_write with type="file".

cc @machow if you wouldn't mind taking a look here!

@machow Thanks!
I tested this with gcs and even rolled it into an ibis PR so I don't think it's a general cloud boards issue.
I'm a bit -1 on returning the result of open since that can leak resources without a with statement, which an end user could do, but then pin_read would some times be a context manager and sometimes not which feels a bit awkward IMO.
My end goal is to be able get all the on disk paths for a given pin, since that is what we're passing to the various readers in ibis.
I think I may be misunderstanding what kind of thing path_to_file is. Is it a str that refers to path on disk, or can it be an object in cloud storage, or can it either?

When you construct a board, it creates the relevant fsspec filesystem (eg s3, gcs, local), so I think path_to_file is read using that filesystem (fs in the load function). I can't remember if the protocol gets included in the path, or if the filesystem itself determines where path is read (eg s3).

I'm a bit -1 on returning the result of open since that can leak resources

Fair 😅! I think I've come around to just doing what this PR does, since..
cc @juliasilge wdyt? For context..

R pins does this via pin_upload/download, but doesn't define any behavior for pin_read here
Since it's undefined behavior, returning the path here seems okay
We can always add a new function later for returning the underlying fsspec files for any type (eg if someone wants to query their parquet file directly on s3)

I am also something of a -1 on pin_read returning a path or fsspec object in the pins context, just because of how hard it is to reason about what a function or method returns when the return type depends on an argument. Like @cpcloud this strikes me as not great:

then pin_read would some times be a context manager and sometimes not

On the R side, this type of task is handled by pin_upload() / pin_download(); notice that pin_download() returns a vector of paths instead of the contents of the pin like pin_read().
Is it doable to implement pin_upload / pin_download methods, perhaps returning the fsspec file object, instead of adding type = "file"?

This article might be a relevant thing to take a look at, for how we recommend folks handle files they want to read/write in a custom way:
https://pins.rstudio.com/articles/managing-custom-formats.html

Hm, I was hoping my use case isn't that custom: I don't want a DataFrame out of pin_x, I want the set of cached on-disk paths that make up the dataset. Should I be using pin_download for that?

Hm, I was hoping my use case isn't that custom

Oh for sure, maybe I just made things more confusing by showing what folks can use pin_upload / pin_download for.

I want the set of cached on-disk paths that make up the dataset. Should I be using pin_download for that?

My opinion is yes, for consistency across our language implementations of pins. Neither is implemented yet though for Python:
https://github.com/rstudio/pins-python/blob/7ded06943c6ea3236e5da4443a3869073d66aeb1/pins/boards.py#L347
What do you all think of these methods returning the fsspec file directly, rather than the path, like @machow mentioned?

For my use case it would be less than ideal to get back an fsspec path, unless I can get a filename from that to the cached path on disk.
I'd like pins to be able to handle the downloading, caching, and checking for new data without having to deal with whatever cloud file system thing that ultimately backs the pin.

Sorry, to be clear what I mean is my ideal signature is this:
def pin_download(...) -> list[Path]: # or list[str]

def pin_download(...) -> list[Path]: # or list[str]

This is extremely consistent with the R pin_download so to me, this sounds like the best way to go. 👍

I think this all makes sense! Just to be sure to recap:

@cpcloud's implementation currently has pin_read() return the paths.
Let's use this exact behavior, but change it from using pin_read() to using pin_download() / pin_upload().

@cpcloud do you mind if I pick up the PR from here? (should be able to make the changes tomorrow). Since pin_download() and pin_upload() aren't implemented, I'll need to make some quick tweaks, but shouldn't be too bad!

Sgtm, take whatever you need!

Just wanted to chime in and say the proposed API would fit our needs perfectly as well, so thanks for working on this 🙏

Alright, tests are passing with basic pin_upload() / pin_download() behavior.
Currently,

pin_upload() just calls pin_write(), which always writes the file name as {pin_name}.{suffixes}

E.g. uploading the file "mtcars.csv" to the pin "my_cool_pin" names the file "my_cool_pin.csv" (but it should preserve mtcars.csv)
Need to pull out most of pin_write() into a separate method, so we can preserve the exact file name

pin_download() checks to ensure there's a cache to download to, errors otherwise.
pin_read() fails as expected for type="file"

(Will also add pin_download/upload to docs)

@isabelizimm when you get the chance, do you mind taking a look? I think the pin_download() / pin_upload() behavior should be implemented! (Though we still need to document them)

@machow @isabelizimm Thanks for pushing this through ❤

Thanks again for working on this!
Is there any ETA on when a release with this change will be published?
I know from experience it is annoying when people ask this 😄, but we have a use case it would be perfect for it and I am trying to figure out if I should wait for a release or pull these changes in sooner manually.

Great question @jimhester! We're planning on a release by the end of August; it's on the to-do list for @machow and I as I transition into the maintainer role. 😄

Following up here-- @jimhester pins 0.8.2 has been released!


V2 -- Split test directory in unit and functional tests

What is your opinion on splitting the root test directory into
test/
  func/
    ... everything that is currently under test/
  unit/
    ... root directory for unit tests run by mocha

Currently I've added a mocha run script to package.json.
"mocha": "./node_modules/mocha/bin/mocha --require babel-core/register"

and run some unit tests by:
npm run mocha -- test/fixtures/qaFixturesTest.js --watch

That's a quite manual way and it would probably be nicer api for our users if there were run scripts like npm run test:unit, npm run test:func. npm run test would run both of them.

I am sorry that I do not completely understand the reason for this. If you have unit tests (e.g. for utility methods...), why dont we just add them into the current test structure? In this way you would in fact use them as more functional tests, that is true. But things like coverage information etc. are a lot harder to do if you have two test runners. Are there any benefits that I currently do not see?
I had the whole test setup working without karma, too. But it just felt incorrect as you have to monkey-patch webpacks require calls. You may see the last approaches of this when checking out https://github.com/react-webpack-generators/react-webpack-template/commit/bff1648815210.
Maybe this is something that we should move for instead of karma? All tests will run in a speed not compareable to the webpack based tests currently used...

Generating test reports with multiple test runners is a fair point, haven't thought about that. Shipping a ready-to-go Karma integration seems very valuable to me, as in combination with Enzyme it can be used for advanced tests not possible otherwise.
A bulk of simpler tests is fine (and much faster) with Mocha and outside of Webpack (utility logic, business logic, etc.). Also if I am not mistaken FB will publish a new test helper that can do simple assertions on rendered components based purely on the node runtime, so asserting some classes and the like could become cheaper outside of Karma.
Most of all I am -1 for dropping Karma, but my initial pros for a separate unit test runner were

speed of a test run (no expensive spin-up)
mocha cli options (mainly the grep and fgrep options to run particular tests)
IDE integration (although many IDEs support both, mocha and karma tests)

Maybe it is an option to let the Karma test runner process all tests, but have a purely node based test runner configured to run a subset of them (is this what you meant with adding them in the current test structure?). At least this matches my workflow in most projects, where I have unit tests evaluating all the time, and the more expensive functional tests only on commit.

You may even run the tests with mocha alone, which is really blazing fast (and running with the "native" mocha/chai pair, including all available plugins and stuff there like). The test framework is really fat as it is configured currently. The question is, if you need functional tests (in the way books describe them), would it not be better to use something like selenium or webdriver.io for this and use regular unit tests the way it is meant to be? It would really speed up if we would use mocha instead of karma out of the box. There are just some edge cases (e.g. hard integration of cookies, localStorage or websocket connections) that cannot be handled via jsdom.
Have to think about this closer I think.

I'd argue that Karma also offers a lot in the area of functional testing (e.g. capturing tests from browsers, even with integration of services like Browserstack or something). That's why I enjoy that the basic configuration for it is available out of the box.
However, the argument that the tests that we ship with the generator don't require Karma, but run perfectly fine on Mocha and wo/ taking so much time to launch is absolutely valuable.
Would it be an option for you to think in a direction where we refactor the main testing facilities to use mocha cli as test runner, but also keep a configuration and command for Karma tests? Another option would be to create a sub generator that injects a karma setup for people who like to opt in.

I had the whole test setup working without karma, too. But it just felt incorrect as you have to monkey-patch webpacks require calls.

The one thing I've noticed is that it will obviously stumble upon resolving webpack aliases (as I define imports with relative paths most of the time that wasn't too bad for me). Is that an aspect of the monkey-patching you refer to or are there more issues that require monkey-patching?

Yes, that is what I meant. Also, you have to add each extension that has a loader for webpack to the mocha exclude pseudo null loader that is patched. You can see this in https://github.com/react-webpack-generators/react-webpack-template/blob/208de3d08d546e80c1f6333bfefd09d5dd46573d/conf/mocha/webpackexclude.js#L25. That means whenever a user adds something to the webpack config (or we do), we will also have to add it to this extension array.
The webpack-alias may also be another problem a user could run into, but as I opted to just return nothing (for completely skipped stuff) or the filename (for images, svgs and the like) that was not the problem as nothing will be loaded by babel anyways.
About react testing: This seems to be in flux currently. In one of the core meeting notes it is said that the core React-Devs are looking into dropping the built in test utils (and jest?) completely in favour of enzyme. Enzyme can be used either via shallow rendering (without any dom) or with fakedom (when using render). Both work out of the box currently, on karma as well as on mocha.
Lets look at it like this:
Karma:

is already included

setup is tried and true, runs nicely without any bigger issues

has support for hot reloading out of the box (with current webpack setup)

runs on a "real" browser (or more)

Subsequent tests fail if one assertion fails (e.g. when testing stores)

has much longer spinup times because of webpack + browser

has many (many!) dependencies that affect the toolchains size currently (just look at all those karma-* packages)

does not need any more configuration in enzyme / mocha / whatever directly (most stuff is done via plugins)

Mocha:

is already included, albeit not as testrunner

is much more lightweight as it does not need a browser or webpack at all

makes it possible to grep (to be fair this is in fact also possible with karma, but you will still need to spin up the whole webpack stuff in it)

"Real" Unittests, as each file is tested individually and does not affect the already built application

less problems because no browser is needed (I once ran into a phantom memory leak which made phantomjs-2 unable to run a complete testsuite more than 3 or 4 times, suite had about 2000 tests and 6000 assertions)

eventually missing support for inbrowser stuff (e.g. ajax, websocket, localStorage...). This means you WILL always need something like sinon to stub/mock those stuff. Can (but must not) be a problem when using flux with remote sources.

we will likely have to maintain the fake webpack loader for it to work. I do not have any deeper insights into this, so it may be tricky to support.

If you wanto to have integration or functional tests, you need to setup something like webdriver.io, karma or whatever yourself.

I have to say I am a bit torn here :).

that's a great response, thanks! Just for reference: with react testing I was referring to the react-test-renderer which was released just the other day. There seems to be a problem when using it in the same file with Enzyme test currently (see issue no. 7386 in the react issue queue). In no way this is comprehensible to what Enzyme has to offer, but I'd at least expect people to ask about using it.

FWIW, starting up the Karma runner to get the first results takes a little over 2 minutes on a fairly moderate project right now (limited hardware plus the need for the webpack build chain + spinning up a browser).
The tests themselves and subsequent runs in watch mode run super quick, but the startup time was the initial reason I started running many of the tests with Mocha only. I will have tests that need Karma's advanced features (or as you wrote something different in that direction like Selenium), so I wouldn't kick the Karma config out of my project.
To solve the reporting problem I simply have Karma run all of my tests, wheres the Mocha runner runs a subset of them. I understand that this might not be desirable as a default, but in the current use case it does its job. 😄


Revert "Checkpoint 1 - Inverted Index"

Reverts andela-anwosu/inverted-index-cp1#1

Coverage decreased (-5.9%) to 94.118% when pulling feb07547fe59b2a558f9c9770c71f145ec818a90 on revert-1-develop into 0f19687ee621f2b9d8175b60574194bb3327fe58 on master.

Coverage decreased (-5.9%) to 94.118% when pulling feb07547fe59b2a558f9c9770c71f145ec818a90 on revert-1-develop into 0f19687ee621f2b9d8175b60574194bb3327fe58 on master.


When exiting visual mode there is a delay up to 5 seconds before the color changes

The issue seems to be present when configuring the extension via vimscript.
Changing the config to lua and loading via nvim_exec the issue is still present but behaves differently.
-- init.lua

vim.api.nvim_exec([[
    ...config
]], false

When loaded in Lua the Visual modes work as follows

Visual Mode: delay on entering (apx 2 seconds), very slight delay/none on exit
Visual Line mode: no delay on entrance,  very slight delay on exit.

The delay when entering Visual Mode is negated when pressing any button with the color changing as soon as a button is pressed. This makes the issue a lot less noticeable.
A new release will be created updating the README to recommend configuring in Lua to minimize the issue. It will also change the default advice to include the status bar and cursor, @simonjonathan mentioned he only uses the plugin for the cursor color. It makes a lot of sense as your eyes are already there so I'm happy to make this the default recommendation.

This has been addressed via the latest changes (0.1.2) pushed to master (needs renaming) but I'm having issues uploading it to the package registry. I will upload ASAP

Resolved via Release V0.1.3


Feat: View file previews with treesitter color

The only thing i miss from other file explorers, is that the file preview doesnt show syntax color

Let me know if this feature is added


How can I access graphical execution plan?

System information:
Linux Mint 19.2
DBeaver CE 6.2.4
Connection specification:
PostgreSQL 10.10
Describe your question:
Two blog posts from the past year show a graphical version of the execution plan:

https://dbeaver.com/2019/03/12/dbeaver-6-0-is-a-new-big-step-forward/
https://dbeaver.com/2019/06/11/start-your-summer-with-new-dbeaver-6-1/

According to the first link, this is available for PostgreSQL (and other databases).
However, when I explain the execution plan, I only get the "Simple" version. In the blog post images, there is a "Graph" tab in the Execution plan pane which I just do not see.
Why would this be missing? Do I have to do something to enable this feature? Is this an EE feature only?
Not calling this a bug report because I'm not sure what the expected behavior is.

Hi @leehach ,
yes, graphical version of the execution plan is EE feature only


Change return type by type guard

class Foo {
  foo = 123;
}
class Bar {
  bar = 123;
}
function distinguish(arg: Foo | Bar): Foo | Bar {
  if(arg instanceof Foo) {
    return arg
  }
  else {
    return arg
  }
}
let result: Foo = distinguish(new Foo())
// Type 'Foo | Bar' is not assignable to type 'Foo'

I'm not sure what you're asking or what the motivating scenario is, but would this fix it?
function distinguish<T extends Foo | Bar>(arg: T): T {
  if (arg instanceof Foo) {
    return arg
  }
  else {
    return arg
  }
}


Nickname sanitizer command

Required implementation of nickname command.
Requirements

Enable/disable sanitizing feature
Show current settings
Possibly, make ability to choose between several sanitizing modes

This issue is related with #40 but can be implemented without this module. This command only changing values in database.


[BUG] Contributor count breaks with an NPE when encountering an empty repo.

Describe the bug
When running the contributor count utility, it throws an NPE when it encounters a repository that does not contain code.  The enumeration ends.
Expected behavior
It should see the repo is empty and move on without stopping the enumeration.
Actual behavior
While enumerating an org's repos, it encountered a repo with no code in it.  It threw an NPE and exited the program.
Steps to reproduce

Use a GitHub org (it probably does the same in other SCMs, I only tried GitHub)
Create a new repository, don't add any files to it.
Run the contributor count tool to enumerate the org.

Environment
CLI 2.0.58
Powershell on an unknown Windows version.
Additional comments
N/A
Logs

Hi @nleach999
Thanks for raising the issue. We are currently fixing it under #599


"Mark Paid" and "Mark Eligible" buttons are broke

gots to fix it before signups on Saturday

We fixed this a long time ago :\


my  monitoring-grafana  status CrashLoopBackOff

I follow the steps to install heapster
Finally appeared：
kube-system   etcd-master                             1/1       Running            0          1d
kube-system   heapster-84017538-t8f69                 1/1       Running            0          3h
kube-system   kube-apiserver-master                   1/1       Running            0          1d
kube-system   kube-controller-manager-master          1/1       Running            0          1d
kube-system   kube-dns-2425271678-0kh71               3/3       Running            0          1d
kube-system   kube-proxy-8xkgh                        1/1       Running            0          1d
kube-system   kube-proxy-qxc22                        1/1       Running            0          1d
kube-system   kube-proxy-zvmmj                        1/1       Running            0          1d
kube-system   kube-scheduler-master                   1/1       Running            0          1d
kube-system   kubernetes-dashboard-2209332821-w4zb0   1/1       Running            0          1d
kube-system   monitoring-grafana-762361155-88f60      0/1       CrashLoopBackOff   46         3h
kube-system   monitoring-influxdb-2097753575-d9v81    1/1       Running            0          3h
kube-system   weave-net-6pklf                         2/2       Running            0          1d
kube-system   weave-net-d3pr0                         2/2       Running            1          1d
kube-system   weave-net-hlt7n                         2/2       Running            0          1d

View the pod log：
[root@master httpd]# kubectl logs monitoring-grafana-762361155-88f60 -n kube-system
Starting a utility program that will configure Grafana
Starting Grafana in foreground mode
Can't access the Grafana dashboard. Error: Get http://admin:admin@localhost:3000/api/org: dial tcp [::1]:3000: getsockopt: connection refused. Retrying after 5 seconds...
t=2017-07-05T16:37:34+0000 lvl=crit msg="Failed to parse /etc/grafana/grafana.ini, open /etc/grafana/grafana.ini: no such file or directory%!(EXTRA []interface {}=[])"

View the pod describe:
[root@master httpd]# kubectl describe pod monitoring-grafana-762361155-88f60 -n kube-system
Name:		monitoring-grafana-762361155-88f60
Namespace:	kube-system
Node:		node2/<IP_ADDRESS>
Start Time:	Wed, 05 Jul 2017 21:01:24 +0800
Labels:		k8s-app=grafana
		pod-template-hash=762361155
		task=monitoring
Annotations:	kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicaSet","namespace":"kube-system","name":"monitoring-grafana-762361155","uid":"0b875064-6182-11e7-9205...
Status:		Running
IP:		<IP_ADDRESS>
Created By:	ReplicaSet/monitoring-grafana-762361155
Controlled By:	ReplicaSet/monitoring-grafana-762361155
Containers:
  grafana:
    Container ID:	docker://170fc1f19515846c2086989f48ee034dd3a4bb924cd65812972d3e2a95f2b805
    Image:		gcr.io/google_containers/heapster-grafana-amd64:v4.2.0
    Image ID:		docker-pullable://gcr.io/google_containers/heapster-grafana-amd64@sha256:9bf6d8edf8884f19209ca424308e28aa0cbaaeb9f02b4ac237effb6011a09c1f
    Port:		3000/TCP
    State:		Waiting
      Reason:		CrashLoopBackOff
    Last State:		Terminated
      Reason:		Error
      Exit Code:	1
      Started:		Thu, 06 Jul 2017 00:37:34 +0800
      Finished:		Thu, 06 Jul 2017 00:37:34 +0800
    Ready:		False
    Restart Count:	47
    Environment:
      INFLUXDB_HOST:			monitoring-influxdb
      GF_SERVER_HTTP_PORT:		3000
      GF_AUTH_BASIC_ENABLED:		false
      GF_AUTH_ANONYMOUS_ENABLED:	true
      GF_AUTH_ANONYMOUS_ORG_ROLE:	Admin
      GF_SERVER_ROOT_URL:		/
    Mounts:
      /var from grafana-storage (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-wn034 (ro)
Conditions:
  Type		Status
  Initialized 	True
  Ready 	False
  PodScheduled 	True
Volumes:
  grafana-storage:
    Type:	EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
  default-token-wn034:
    Type:	Secret (a volume populated by a Secret)
    SecretName:	default-token-wn034
    Optional:	false
QoS Class:	BestEffort
Node-Selectors:	<none>
Tolerations:	node.alpha.kubernetes.io/notReady:NoExecute for 300s
		node.alpha.kubernetes.io/unreachable:NoExecute for 300s
Events:
  FirstSeen	LastSeen	Count	From		SubObjectPath			Type		Reason		Message
  ---------	--------	-----	----		-------------			--------	------		-------
  3h		4m		48	kubelet, node2	spec.containers{grafana}	Normal		Pulled		Container image "gcr.io/google_containers/heapster-grafana-amd64:v4.2.0" already present on machine
  3h		4m		48	kubelet, node2	spec.containers{grafana}	Normal		Created		Created container
  3h		4m		48	kubelet, node2	spec.containers{grafana}	Normal		Started		Started container
  3h		6s		1023	kubelet, node2	spec.containers{grafana}	Warning		BackOff		Back-off restarting failed container
  3h		6s		1023	kubelet, node2					Warning		FailedSync	Error syncing pod

I want to know how to solve
thanks！

This is a known issue with the current Grafana image, it looks like: duplicate of https://github.com/kubernetes/heapster/issues/1709

@DirectXMan12 thanks!


Fix compatible for webhook ref type

Fix #25185
Caused by #24634

Incomplete. There are others.

@wxiaoguang It's ready now.


feat(templates): Add hostname to templates

Initially just use the Container name as hostname. Later we could additionally offer an Input field to override the hostname
Close #1087

@tfenster
Can you please open an issue as well ? Please read our contributions docs for more details: https://github.com/portainer/portainer/blob/develop/CONTRIBUTING.md

A Docker image is available for this implementation via portainer/portainer:pr1084-win (Windows AMD64 build).

Thanks @tfenster :+1:


This continues to happen for "today's power production" and it totally crushes the graphs. How can I fix this?

There is no way I made 8.8 Megawatts today.....

Current power production works as expected......

The only value that is related is life time production which is 8.8MWh..... so somehow it's pulling that number instead of "today".