8000 Releases · join-monster/join-monster · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Releases: join-monster/join-monster

v4.0.0

01 Jul 13:13
@nicoabie nicoabie
v4.0.0
cc4f328
Compare
Choose a tag to compare
v4.0.0 Latest
Latest

What's Changed

  • Support different arguments for different aliases by @kryops in #482*

Breaking changes:

It is no longer guaranteed that a field's value is available under source[fieldName] in a custom resolver. Instead, custom resolvers on non-trivial fields need to use GraphQL's default resolver to get the field value:

import { defaultFieldResolver } from 'graphql'

const User = new GraphQLObjectType({
  //...
  fields: () => ({
    //...
    following: {
      // ...
      resolve: (source, args, context, info) => {
        const value = defaultFieldResolver(source, args, context, info)
        return processUsers(value)
      }
    }
  })
})

See the docs on custom resolvers for more details.

New Contributors

Full Changelog: v3.3.5...v4.0.0

Contributors

kryops
Assets 2
Loading

v3.3.5

28 May 20:30
@nicoabie nicoabie
v3.3.5
3327ead
Compare
Choose a tag to compare
v3.3.5

What's Changed

Most relevant to users

Other stuff relevant to the project itself

New Contributors

Full Changelog: v3.3.4...v3.3.5

Contributors

nicoabie, jasonwoodland, and dependabot
Loading

v3.3.4

23 May 16:21
@nicoabie nicoabie
v3.3.4
46436fa
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.
Compare
Choose a tag to compare
v3.3.4

What's Changed

New Contributors

Full Changelog: v3.1.1...v3.3.4

Contributors

garymardell, lorensr, and 4 other contributors
Loading

Join Monster V2

27 Jun 23:12
@acarl005 acarl005
v2.0.0
bc9b200
Compare
Choose a tag to compare
Join Monster V2

New features:

  • LIMIT functionality, supported on all fields
  • Fetch columns from junction tables
  • For fields with junctions, you can now specify WHERE and ORDER BY clauses on the junction table or the main table, including paginated fields.
  • Ability to dynamically choose pagination implementation per-request.
  • Better ability to write where functions that depend on args and info from the parent/ancestors.

Breaking changes:

  • Fields with junctions have a new interface in order to support the new features.
  • Any where, orderBy, and sortKey on many-to-many paginated fields used to be applied to the junction table. This has changed, and will be applied to the main table instead in order to be consistent with non-paginated junctions. If the old behavior is desired, you can nest those properties inside the junction object, which is part of the new API.
  • Change 4th parameter of where and sqlExpr to the field's SQL AST Node, which is a lot more useful.
// this...
{
  type: new GraphQLList(User),
  junctionTable: 'relationships',
  sqlJoins: [
    (followers, relations) => `${followers}.id = ${relations}.follower_id`,
    (relations, followees) => `${relations}.followee_id = ${followees}.id`
  ]
}

// is now this...
{
  type: new GraphQLList(User),
  junction: {
    sqlTable: 'relationships',
    sqlJoins: [
      (followers, relations) => `${followers}.id = ${relations}.follower_id`,
      (relations, followees) => `${relations}.followee_id = ${followees}.id`
    ]
  }
}
// this...
{
  type: new GraphQLList(User),
  junctionTable: 'relationships',
  junctionTableKey: [ 'follower_id', 'followee_id' ],
  junctionBatch: {
    thisKey: 'follower_id',
    parentKey: 'id',
    sqlJoin: (relations, followees) => `${relations}.followee_id = ${followees}.id`
  }
}

// is now this...
{
  type: new GraphQLList(User),
  junction: {
    sqlTable: 'relationships',
    uniqueKey: [ 'follower_id', 'followee_id' ],
    sqlBatch: {
      thisKey: 'follower_id',
      parentKey: 'id',
      sqlJoin: (relations, followees) => `${relations}.followee_id = ${followees}.id`
    }
  }
}
// this...
{
  type: UserConnection,
  args: forwardConnectionArgs,
  sqlPaginate: true,
  orderBy: {
    created_at: 'DESC',
    followee_id: 'ASC'
  },
  junctionTable: 'relationships',
  sqlJoins: [
    (followers, relations) => `${followers}.id = ${relations}.follower_id`,
    (relations, followees) => `${relations}.followee_id = ${followees}.id`
  ]
}

// is now this...
{
  type: UserConnection,
  args: forwardConnectionArgs,
  sqlPaginate: true,
  junction: {
    sqlTable: 'relationships',
    sqlJoins: [
      (followers, relations) => `${followers}.id = ${relations}.follower_id`,
      (relations, followees) => `${relations}.followee_id = ${followees}.id`
    ],
    // the order now goes inside the `junction` if you want to sort on the junction table
    orderBy: {
      created_at: 'DESC',
      followee_id: 'ASC'
    }
  }
  // or you could apply the order on the user table by putting it out here
  //orderBy: {
  //  created_at: 'DESC',
  //  id: 'ASC'
  //}
  
  // you could also place a `where` at either
}
Loading

Add Union and Interface Types

17 Mar 08:02
@acarl005 acarl005
v1.2.0
87379c8
Compare
Choose a tag to compare
Add Union and Interface Types 
v1.2.0

add union and interface types
Loading

Release Version 1.0.0

23 Feb 11:34
@acarl005 acarl005
v1.0.0-beta.1
71e841d
Compare
Choose a tag to compare
Release Version 1.0.0 Pre-release
Pre-release

More advanced query planning has arrived! One of the greatest criticisms of Join Monster has been the heavy use of JOINs, which can be an expensive database operation. One of the benefits of DataLoader was the ability to simply batch queries. In this release, Join Monster can do both!

You can plan queries that get all your data in a single request using joins, or you can get them in separate batches with queries that use WHERE IN to get the right data. You can mix these approaches together to find the optimal query plans for your application.

Breaking changes

  • getSQL method removed. No longer makes sense in he new multiple-query paradigm.
  • Offset pagination adds the total to the connection object instead of the pageInfo.

Deprecated

  • 'standard' dialect is deprecated because nothing really implements the standard. The new default is 'sqlite3'.
  • joinTable is deprecated. It was renamed to junctionTable to avoid over-use of the word "join".
Loading

Stable v0

14 Feb 10:50
@acarl005 acarl005
v0.9.9
1d17f34
Compare
Choose a tag to compare
Stable v0

The v0 major version will be stable after this point.

The pre-release of v1.0.0 is coming soon. The most important new feature will be the option to use DataLoader-style batching instead of joins. Join Monster will have more advanced query planning in order to balance the optimizations on network latency due to roundtrips and duplicated data due to joins. Schemas can mix joins and batches to tune the query plans to the heuristics of their application. There will be a few breaking changes.

Q: Is support for Apollo server planned for the near future?

A: We do not use Apollo, so it is not a priority. However, we do want Join Monster to support it, as it is the most highly requested feature. How long this takes will depend largely on community engagement.

Loading
0