Mysql and postgres have snake case convention by default. Since lodash is already a dependency, it'll be very nice to have a model flag and a built-in conversion. Something like this:

class Animal extends Model {
  static get useSnakeCase() {
    return true;
  }
}

The result of turning this flag on will be conversion of output object properties to camel case and input object properties to snake case in model hooks.

I tried using camel case columns in my databases to avoid conversion, but it feels weird after using snake case columns before. There are also some cons of camel case columns - e.g. you have to use quotes in raw sql queries, knex migrations and default database indices/foreign keys use snake case and don't match camel case table and column names.

It'll be very useful to have this feature built in for different purposes.

I'm trying to create Model, which has extended query builder with .session() method. However when I'm extending the model and setting our custom query builder there return type of $query() and other functions still is QueryBuilder<this> instead of CustomQueryBuilder<this>.

Simplified (not runnable example):

class CustomQueryBuilder<T> extends QueryBuilder<T> {
  session(session: any) {
    this.context().session = session;
    return this;
  }
}

class BaseModel extends Model {
  // Override the objection.js query builders classes for subclasses.
  static QueryBuilder = CustomQueryBuilder;
  static RelatedQueryBuilder = CustomQueryBuilder;

  // ... more stuff ...
}

const daa = await BaseModel
          .query(trx)
          // ERROR: [ts] Property 'session' does not exist on type 'QueryBuilder<BaseModel>'
          .session(req.session)
          .insert({1:1});

Any ideas how to override this? I wouldn't like to do casting everywhere I'm using my extended query builder, nor I would like to add extra methods to BaseModel which would apply correct typing for returned query builder.

I'm starting to plan the 2.0 release and I'd like to hear the community's opinions what we should add to objection in 2.0 or later down the road.

I'd like to reiterate here that the goal of objection was never to become Eloquent, Django's ORM, Active Record or any other known ORM. Objection's goal is said pretty well at the top of the github README. Objection is a "query builder on steroids" that never get's in the way of SQL, but still attempts to provide tools for working with repetitive stuff and especially relations.

That said, there are many things those ORMs do better than objection and we should try to bring in the features that suit objection's design goal.

SO, I'd like you to post here what you miss from any other tool you've worked with and think objection should really have. Vote the features using :+1: and :-1:

Couple of things 2.0 will have:

• A more usable and consistent static hook system that fixes most if not all issues I've seen people having. The instance hooks will still be around. They have their use cases.
• More consistent naming of methods and concepts. For example eager is used as a verb, even though it's not, joinRelation implies it joins a single relation. joinEager sounds like joinRelation even though it does a very different thing. These will be something like withGraphFetched, joinRelated, withGraphJoined. etc. The old names will remain as aliases at least until 3.0.

https://github.com/Vincit/objection.js/projects/1

Is there any desire to provide an official plugin listing? I've created two plugins which others may benefit from: objection-timestamp and objection-softdelete.

I just upgrade knex to 0.95.0 and now I'm getting typescript compilation errors in objectionjs like this:

node_modules/objection/typings/objection/index.d.ts:1830:12 - error TS2709: Cannot use namespace 'Knex' as a type.

1830     (knex: Knex, modelClasses: AnyModelConstructor[]): Promise<void>;
                ~~~~

Will support for 0.95 be added soon?

Hey, sorry if I'm out of line here. I've been using Objection.js for a little while and I love it. I have almost no complaints. The library is well designed and the documentation is usually clear and comprehensive.

However, it takes about 10 seconds to become interactive on my extremely modern (6 months old) computer built for computation. Ctrl-F takes forever and isn't that helpful because 9/10 whatever I'm looking for is used in every other example.

I don't know that the right thing to do would be to split it up into multiple pages, but it seems no one has brought this problem up yet, at least in the issues. Could be an area of improvement. I wouldn't be offended if this issue is closed because it's not something the team is particularly interested in improving. It's definitely usable at the moment, but it's a bit of a time suck.

I'm getting the following error after upgrading to 0.8.0:

TypeError: Class constructor Model cannot be invoked without 'new'
  at new UserModel (/path/to/project/src/server/graphql/models/User/userModel.js:29:103)
  at Function.fromDatabaseJson (/path/to/project/node_modules/objection/lib/model/Model.js:443:19)
  at Object.createModels (/path/to/project/node_modules/objection/lib/queryBuilder/QueryBuilder.js:826:41)
  at Object.tryCatcher (/path/to/project/node_modules/bluebird/js/release/util.js:16:23)
  at Promise._settlePromiseFromHandler (/path/to/project/node_modules/bluebird/js/release/promise.js:512:31)
  at Promise._settlePromise (/path/to/project/node_modules/bluebird/js/release/promise.js:569:18)
  at Promise._settlePromise0 (/path/to/project/node_modules/bluebird/js/release/promise.js:614:10)
  at Promise._settlePromises (/path/to/project/node_modules/bluebird/js/release/promise.js:693:18)
  at Async._drainQueue (/path/to/project/node_modules/bluebird/js/release/async.js:133:16)
  at Async._drainQueues (/path/to/project/node_modules/bluebird/js/release/async.js:143:10)
  at Immediate.Async.drainQueues (/path/to/project/node_modules/bluebird/js/release/async.js:17:14)
  at runCallback (timers.js:672:20)
  at tryOnImmediate (timers.js:645:5)
  at processImmediate [as _immediateCallback] (timers.js:617:5)

Currently all relation expressions are strings. Should we add an alternative object representation for them?

Reasons to add something like this:

1. object expressions would be easier to create and inspect programmatically
2. Simple array expressions are just an array of relation names, which is intuitive and clean.

Reasons to not add something like this:

1. Multiple ways to do the same thing.
2. Aliases and filters are difficult to add while keeping the expressions simple.

Here's some examples how this could work:

Simple relation expressions

// All following are equivalent:

// string
const e1 = `[a, b.c]`;

// array of strings
const e2 = ['a', 'b.c'];

// all objects
const e3 = {
  a: {},
  b: {
    c: {}
  }
}

// all objects 2
const e4 = {
  a: true,
  b: {
    c: true
  }
}

// combination of objects and arrays
const e5 = {
  a: {},
  b: ['c']
}

Expressions with aliases and filters

// All following are equivalent:

// string
const e1 = `[
  a(f1) as aa, 
  b(f2).c(f3, f4)
]`;

// array of strings
const e2 = [
  'a(f1) as aa', 
  'b(f2).c(f3, f4)'
];

// all objects (ugly as hell)
const e3 = {
  'a(f1) as aa': true,
  'b(f2)': {
    'c(f3, f4)': true
  }
}

// combination of objects and arrays  (ugly as hell)
const e4 = {
  'a(f1) as aa': true,
  'b(f2)': ['c(f3, f4)']
}

// all objects, filters and aliases using special properties:
const e5 = {
  a: {
    $alias: 'aa',
    $filter: ['f1']
  },

  b: {
    $filter: ['f2']

    c: {
      $filter: ['f3', 'f4']
    }
  }
}

Alternative verbose syntax

// All following are equivalent:

// string
const e1 = `[
  a(f1) as aa, 
  b(f2).c(f3, f4)
]`;

const e2 = [
  {
    name: 'a',
    filter: 'aa'
  },
  {
    name: 'b'
    filter: ['f2'],

    children: [
      {
        name: 'c',
        filter: ['f3', 'f4']
      }
    ]
  }
]

So what do you think? Should this be added and with which syntax? If you have an alternative syntax in mind, I'd love to hear it.

When validation errors happen in graph inserts and upserts of nested relations data, Objection currently doesn't specific the location of the error.

This PR calculated dataPaths for graph inserts and upserts, and then provides these as relative JSON pointers instead of plain property names in the validation errors. If the data is only on the root level of the graph, then these two behaviors are actually the same.

As discussed on Gitter, the convention of how to handle JSON pointers, and wether they should be absolute or relative paths to the data still needs some more thought and a proper decision.

For now, here the current state of things, so the discussion can be continued on in the issue here.

As discussed before, here now the PR to add this.

This is a follow up PR for #583, I will rebase once that one is merged.

Please note that there are things to be figured out still, as outlined in this comment:

// TODO: Should we distinguish between update and patch for noUpdate also?
// If we want different options, then:
// return hasOption(node, 'update')
//   ? decideType(node, UpsertNodeType.Update, 'noUpdate')
//   : decideType(node, UpsertNodeType.Patch, 'noPatch');

Note that 'noUpdate' in the current code base would become 'noPatch' if we did this.

I have a query that looks similar to this:

Thing.query().first().select(
    "thingId", "creationTime", "author.emailAddress"
).joinRelation("author" /* Join on users table */ ).where({
    "thingId": thingId
}).then(thing => doStuff(thing))

Both the thing and user tables have a creationTime column. When I try to express the query like above I get an error column reference "creationTime" is ambiguous.

One solution would be to do this, but I really don't want to because it's verbose and repetitive and I'd have to do it in lots of places. It wouldn't help maintainability at all.

Thing.query().first().select(
    "thingId", "thingSchemaName.thingTableName.creationTime", "author.emailAddress"
).joinRelation("author" /* Join on users table */ ).where({
    "thingId": thingId
}).then(thing => doStuff(thing))

What I would very much like to do and would expect to be able to do - except I haven't worked out any way how - is to select the model table with an alias. Something nice and sensible and readable like

Thing.query().as("thing").first().select(
    "thing.thingId", "thing.creationTime", "author.emailAddress"
).joinRelation("author" /* Join on users table */ ).where({
    "thing.thingId": thingId
}).then(thing => doStuff(thing))

Or, it would be quite nice if objection was able to automagically prepend the models' table name to selected columns that don't otherwise specify.

What's the best way to fix this?

Removes ansi-html. It's no longer used after updating ancestor dependency webpack-dev-server. These dependencies need to be updated together.

Removes ansi-html

Updates webpack-dev-server from 3.11.2 to 3.11.3

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

Bumps ansi-regex from 4.1.0 to 5.0.1.

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

Hello, do you have an example with models that contain nested relationships between different databases?

For example if you had an Order model which hasMany Items which are on the same DB but then the Items have a manufacturer which is on another DB I know if they were non nested I would use two queries with different transaction knex connections:

        await order.$fetchGraph(
           '[items]',
          {transaction: this.ordersDB.getConnection()}
        )

      await order.$fetchGraph(
         '['items.manufacturer']',
         {transaction: this.manufacturerDB.getConnection()}
       )

But If like in my given example the relation is through a model which lives on the same DB but the relation on that model lives on another DB how would that be achieved?

Thanks for any support/guidance let me know if you need me to clarify anything

Hello, do you have a solution/implementation example of having models with relationships between different databases?

For example we were planning to use inject models into repositories with the correct DB instance to which they correlate to example:

injectedModel.withGraphFetched('[relationOnDifferentDB, relationOnSameDB]') but it seems this assumes that all relations are on the same DB connection which was injected into the model which fails, has anyone encountered this issue or found a good solution?

Bumps decode-uri-component from 0.2.0 to 0.2.2.

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