Skip to content

Latest commit

聽

History

History
2917 lines (2402 loc) 路 137 KB

CHANGELOG.md

File metadata and controls

2917 lines (2402 loc) 路 137 KB
Raw

postgraphile

5.0.0-beta.26

Patch Changes

  • #2071 582bd768f Thanks @benjie! - GrafastExecutionArgs now accepts resolvedPreset and requestContext directly; passing these through additional arguments is now deprecated and support will be removed in a future revision. This affects:

    • grafast()
    • execute()
    • subscribe()
    • hookArgs()

    graphile-config has gained a middleware system which is more powerful than it's AsyncHooks system. Old hooks can be emulated through the middleware system safely since middleware is a superset of hooks' capabilities. applyHooks has been renamed to orderedApply (because it applies to more than just hooks), calling applyHooks will still work but is deprecated.

    馃毃 grafast no longer automatically reads your graphile.config.ts or similar; you must do that yourself and pass the resolvedPreset to grafast via the args. This is to aid in bundling of grafast since it should not need to read from filesystem or dynamically load modules.

    grafast no longer outputs performance warning when you set GRAPHILE_ENV=development.

    馃毃 plugin.grafast.hooks.args is now plugin.grafast.middleware.prepareArgs, and the signature has changed - you must be sure to call the next() function and ctx/resolvedPreset can be extracted directly from args:

     const plugin = {
   grafast: {
-    hooks: {
+    middleware: {
-      args({ args, ctx, resolvedPreset }) {
+      prepareArgs(next, { args }) {
+        const { requestContext: ctx, resolvedPreset } = args;
         // ...
+        return next();
       }
     }
   }
 }

    Many more middleware have been added; use TypeScript's autocomplete to see what's available until we have proper documentation for them.

    plugin.grafserv.hooks.* are still supported but deprecated; instead use middleware plugin.grafserv.middleware.* (note that call signatures have changed slightly, similar to the diff above):

    • hooks.init -> middleware.setPreset
    • hooks.processGraphQLRequestBody -> middleware.processGraphQLRequestBody
    • hooks.ruruHTMLParts -> middleware.ruruHTMLParts

    A few TypeScript types related to Hooks have been renamed, but their old names are still available, just deprecated. They will be removed in a future update:

    • HookObject -> FunctionalityObject
    • PluginHook -> CallbackOrDescriptor
    • PluginHookObject -> CallbackDescriptor
    • PluginHookCallback -> UnwrapCallback

  • Updated dependencies [582bd768f]:

5.0.0-beta.25

Patch Changes

5.0.0-beta.24

Patch Changes

5.0.0-beta.23

Patch Changes

5.0.0-beta.22

Patch Changes

5.0.0-beta.21

Patch Changes

5.0.0-beta.20

Patch Changes

5.0.0-beta.19

Patch Changes

5.0.0-beta.18

Patch Changes

5.0.0-beta.17

Patch Changes

5.0.0-beta.16

Patch Changes

5.0.0-beta.15

Patch Changes

5.0.0-beta.14

Patch Changes

5.0.0-beta.13

Patch Changes

5.0.0-beta.12

Patch Changes

5.0.0-beta.11

Patch Changes

5.0.0-beta.10

Patch Changes

5.0.0-beta.9

Patch Changes

5.0.0-beta.8

Patch Changes

5.0.0-beta.7

Patch Changes

5.0.0-beta.6

Patch Changes

5.0.0-beta.5

Patch Changes

5.0.0-beta.4

Patch Changes

5.0.0-beta.3

Patch Changes

5.0.0-beta.2

Patch Changes

5.0.0-beta.1

Patch Changes

5.0.0-alpha.20

Patch Changes

5.0.0-alpha.19

Patch Changes

5.0.0-alpha.18

Patch Changes

5.0.0-alpha.17

Patch Changes

5.0.0-alpha.16

Patch Changes

5.0.0-alpha.15

Patch Changes

  • #417 e7dd2e039 Thanks @benjie! - codec is now baked into NodeId handlers (rather than using codecName and looking that up in codecs). All related APIs have thus simplified, e.g. the step node(codecs, handler, $id) is now node(handler, $id), etc. TypeScript should point out any issues you have hopefully.

  • #417 620f9e07e Thanks @benjie! - Grafast now supports operationsCacheMaxLength and operationOperationPlansCacheMaxLength configuration via schema.extensions.grafast.*. Currently undocumented.

  • #417 881672305 Thanks @benjie! - deepEval has been renamed to applyTransforms

  • #418 9ab2adba2 Thanks @benjie! - Overhaul peerDependencies and dependencies to try and eliminate duplicate modules error.

  • #417 ff4395bfc Thanks @benjie! - Grafast operation cache now tied to the schema, so multiple schemas will not cause degraded performance from clearing the cache.

  • #417 502b23340 Thanks @benjie! - preset.grafast.context second parameter is no longer the existing GraphQL context, but instead the GraphQL request details (which contains the contextValue). If you were using this (unlikely), add .contextValue to usage of the second argument.

  • #417 dc94b4a30 Thanks @benjie! - Rename 'postgraphilePresetAmber' to 'PostGraphileAmberPreset'

  • #410 4eda0cd57 Thanks @benjie! - Use a single behavior check per location.

    In the past two weeks I added a few behavior strings like array:attribute:filterBy (a scoped form of attribute:filterBy to only be used by attributes that were arrays); however I've realised that this will require plugin authors to implement all the same logic to figure out what type an attribute is in order to then see if it has the relevant behavior. This goes against the design of the behavior system, and makes plugin authors' lives harder. So I've reverted this, and instead used the entityBehaviors system to add or remove the base attribute:filterBy (etc) behavior depending on what the type of the attribute is.

  • Updated dependencies [e7dd2e039, 620f9e07e, f115b6fb2, 1882e0185, 881672305, e5012f9a1, 9ab2adba2, 47f6f018b, ff4395bfc, 502b23340, 4eda0cd57]:

5.0.0-alpha.14

Patch Changes

5.0.0-alpha.13

Patch Changes

  • #402 70b2c3900 Thanks @benjie! - pgCodecAttribute behavior now uses attributeName rather than attribute spec in the callback (BREAKING)

  • #402 37d829b89 Thanks @benjie! - Ability to control whether the nodeId or regular column CRUD mutations are used

  • #402 ff91a5660 Thanks @benjie! - Added postgraphile/presets/relay preset:

    • Hides primary key columns from output schema, and includes id: ID instead
    • Hides foreign key columns from output schema, expecting you to use the relation instead
    • Hides columns that are part of the primary key from update/delete mutations (but still present for create if the column is writeable - it shouldn't be)
    • Hides columns that are part of a foreign key from CRUD mutations/filters, instead exposes the ID for the remote side of the relation
    • Does not allow ordering by individual primary key columns (though you can still order by PRIMARY_KEY_ASC/DESC)
    • Does not allow ordering by individual foreign key columns
    • Turns off the row fetchers that don't use the node ID
    • Turns off the CRUD mutations that don't use the node ID
    • Functions can now use @arg0variant nodeId to indicate the first argument (increase the 0 for other arguments) should accept a node ID (this currently only works where the argument type is a table type)
    • Removes relations from mutation payloads, these should be traversed via the record instead (they're redundant)

    Most of these changes are reversible, so for example if you really want to turn back on Query.userByUsername you can do so by adding the +connection behavior to the "unique username" constraint on the users table.

  • #402 644938276 Thanks @benjie! - Use file:// URLs in import() to fix compatibility with Windows (e.g. when loading graphile.config.mjs)

  • #402 47365f0df Thanks @benjie! - Add helper for more easily handling NodeIDs for known typeName.

  • #402 339cb005e Thanks @benjie! - Remove relations from mutation payloads (unless using V4 preset) - they're redundant.

  • Updated dependencies [70b2c3900, 37d829b89, ff91a5660, 644938276, 47365f0df, 339cb005e]:

5.0.0-alpha.12

Patch Changes

5.0.0-alpha.11

Patch Changes

  • #349 a94f11091 Thanks @benjie! - Overhaul behavior system

    Previously the behavior system worked during the schema building process, inside the various schema hooks. So looking at the behavior of a relation might have looked like:

    GraphQLObjectType_fields_field(field, build, context) {
  const relation = context.scope.pgRelationOrWhatever;

  // Establish a default behavior, e.g. you might give it different default behavior
  // depending on if the remote table is in the same schema or not
  const defaultBehavior = someCondition(relation) ? "behavior_if_true" : "behavior_if_false";

  // Now establish the user-specified behavior for the entity, inheriting from all the
  // relevant places.
  const behavior = getBehavior([
    relation.remoteResource.codec.extensions,
    relation.remoteResource.extensions,
    relation.extensions
  ]);

  // Finally check this behavior string against `behavior_to_test`, being sure to apply
  // the "schema-time smart defaulting" that we established in `defaultBehavior` above.
  if (build.behavior.matches(behavior, "behavior_to_test", defaultBehavior)) {
    doTheThing();
  }

    This meant that each plugin might treat the behavior of the entity different - for example postgraphile-plugin-connection-filter might have a different someCondition() under which the "filter" behavior would apply by default, whereas the built in condition plugin might have a different one.

    Moreover, each place needs to know to call getBehavior with the same list of extension sources in the same order, otherwise subtle (or not so subtle) differences in the schema would occur.

    And finally, because each entity doesn't have an established behavior, you can't ask "what's the final behavior for this entity" because it's dynamic, depending on which plugin is viewing it.

    This update fixes all of this; now each entity has a single behavior that's established once. Each plugin can register entityBehaviors for the various behavior entity types (or global behaviors which apply to all entity types if that makes more sense). So the hook code equivalent to the above would now be more like:

    GraphQLObjectType_fields_field(field, build, context) {
  const relation = context.scope.pgRelationOrWhatever;
  // Do the thing if the relation has the given behavior. Simples.
  if (build.behavior.pgCodecRelationMatches(relation, "behavior_to_test")) {
    doTheThing();
  }

    This code is much more to the point, much easier for plugin authors to implement, and also a lot easier to debug since everything has a single established behavior now (except refs, which aren't really an entity in their own right, but a combination of entities...).

    These changes haven't changed any of the schemas in the test suite, but they may impact you. This could be a breaking change - so be sure to do a schema diff before/after this.

  • #355 1fe47a2b0 Thanks @benjie! - MAJOR BREAKING CHANGE: implicit application of args/input fields has been removed.

    Previously we would track the fieldArgs that you accessed (via .get(), .getRaw() or .apply()) and those that you did not access would automatically have their applyPlan called, if they had one. This isn't likely to be particularly useful for pure Grafast users (unless they want to adopt this pattern) but it's extremely useful for plugin-based schemas as it allows plugins to add arguments that can influence their field's plan without having to wrap the field's plan resolver function. This is fairly critical, otherwise each behavior added (first:, condition:, orderBy:, filter:, ignoreArchived:, etc etc) would wrap the plan resolver with another function layer, and they would get messy.

    However, implicit is rarely good. And it turns out that it severely limited what I wanted to do for improving the fieldArgs APIs.

    I decided to remove this implicit functionality by making it more explicit, so now args/input fields can specify the relevant autoApplyAfterParent{Plan,SubscribePlan,InputPlan,ApplyPlan}: true property and we'll only apply them at a single level.

    From a user perspective, little has changed. From a plugin author perspective, if you were relying on the implicit applyPlan then you should now add the relevant autoApply* property next to your applyPlan method.

  • #363 bcfffd5fe Thanks @benjie! - Fix bug causing @foreignKey relation to not show up under rare circumstances (by updating PgRelationsPlugin to use codec, not resource, as the primary entity).

  • #362 e443db39b Thanks @benjie! - Use original case for table resource names.

  • Updated dependencies [56237691b, ed1982f31, a94f11091, 1fe47a2b0, 198ac74d5, 6878c589c, 2ac706f18, 77e011294, bcfffd5fe, dad4d4aae, e443db39b]:

5.0.0-alpha.10

Patch Changes

5.0.0-alpha.9

Patch Changes

5.0.0-alpha.8

Patch Changes

5.0.0-alpha.7

Patch Changes

5.0.0-alpha.6

Patch Changes

5.0.0-alpha.5

Patch Changes

5.0.0-alpha.4

Patch Changes

5.0.0-alpha.3

Patch Changes

5.0.0-alpha.2

Patch Changes

  • #305 3cf35fdb4 Thanks @benjie! - 馃毃 Ruru is now a CommonJS module, no longer an ESM module.

    Ruru CLI now reads options from a graphile.config.ts file if present.

    It's now possible to customize the HTML that Ruru is served with (specifically the meta, title, stylesheets, header JS, body content, body JS, and init script), either via configuration:

    import { defaultHTMLParts } from "ruru/server";

const preset: GraphileConfig.Preset = {
  //...
  ruru: {
    htmlParts: {
      titleTag: "<title>GraphiQL with Grafast support - Ruru!</title>",
      metaTags:
        defaultHTMLParts.metaTags +
        `<meta name="viewport" content="width=device-width, initial-scale=1" />`,
    },
  },
};

    or via a plugin, which allows you to change it on a per-request (per-user) basis:

    const RuruMetaPlugin: GraphileConfig.Plugin = {
  name: "RuruMetaPlugin",
  version: "0.0.0",
  grafserv: {
    hooks: {
      ruruHTMLParts(_info, parts, extra) {
        // extra.request gives you access to request details, so you can customize `parts` for the user

        parts.metaTags += `<meta name="viewport" content="width=device-width, initial-scale=1" />`;
      },
    },
  },
};

  • #307 7c45eaf4e Thanks @benjie! - 馃毃 'application/x-www-form-urlencoded' is now opt-in (unless you're using the V4 preset).

    CSRF and CORS are tricky topics. When you use PostGraphile as part of a larger system, it's your responsibility to ensure that you don't open yourself up to CSRF/etc issues (e.g. by using CSRF/XSRF tokens, by using SameSite cookie policies, by checking the Origin of requests, or by using a combination of these or other techniques).

    Out of the box, PostGraphile does not use cookies, so any cross-origin requests are harmless because an attacker without the actual user token in hand can only execute unauthenticated requests.

    However, once cookies (and sessions) enter the equation, suddenly CSRF becomes a risk. Normally you cannot submit an Content-Type: application/json request cross origins (unless you've enabled CORS), so this content type doesn't open CSRF issues on its own, but Content-Type: application/x-www-form-urlencoded can be submitted cross origins without CORS policies. The attacker won't be able to view the response, but that doesn't mean they can't cause havoc by triggering dangerous mutations using the user's credentials.

    We've decided to take the stance of making application/x-www-form-urlencoded opt-in; you can opt-in via your graphile.config.ts (or equivalent) like so:

    import { DEFAULT_ALLOWED_REQUEST_CONTENT_TYPES } from "grafserv";

const preset: GraphileConfig.Preset = {
  //...

  grafserv: {
    //...

    allowedRequestContentTypes: [
      ...DEFAULT_ALLOWED_REQUEST_CONTENT_TYPES,
      "application/x-www-form-urlencoded",
    ],
  },
};

    If you're using the V4 preset then we pull in the V4 behavior of enabling this content type by default (since you presumably already have protections in place); however we recommend disabling this media type if you're not using it:

    import { DEFAULT_ALLOWED_REQUEST_CONTENT_TYPES } from "grafserv";

const preset: GraphileConfig.Preset = {
  //... extends V4 preset ...

  grafserv: {
    //...

    allowedRequestContentTypes: DEFAULT_ALLOWED_REQUEST_CONTENT_TYPES,
  },
};

    Note that this media type is not currently part of the GraphQL-over-HTTP specification so disabling it does not make your server non-compliant.

  • Updated dependencies [3cf35fdb4, 7c45eaf4e, 3df3f1726]:

5.0.0-alpha.1

Patch Changes

5.0.0-1.3

Patch Changes

5.0.0-1.2

Patch Changes

5.0.0-1.1

Patch Changes

  • #279 2df36c5a1 Thanks @benjie! - description moved out of extensions to live directly on all the relevant entities.

  • #279 a73f9c709 Thanks @benjie! - PgConnectionArgFirstLastBeforeAfterPlugin is now PgFirstLastBeforeAfterArgsPlugin (because it applies to lists as well as connections). PgInsertStep/pgInsert()/PgUpdateStep/pgUpdate()/PgDeleteStep/pgDelete() are now PgInsertSingleStep/pgInsertSingle()/PgUpdateSingleStep/pgUpdateSingle()/PgDeleteSingleStep/pgDeleteSingle() (to make space to add a future bulk API if we want to). config.schema.orderByNullsLast is now config.schema.pgOrderByNullsLast for consistency (V4 preset users are unaffected). Lots of field scopes in graphile-build-pg have been updated to incorporate field into their names.

  • #267 159735204 Thanks @benjie! - Add formatting for SQL aliases

  • #270 ef42d717c Thanks @benjie! - SQL is now generated in a slightly different way, helping PostgreSQL to optimize queries that have a batch size of 1. Also removes internal mapping code as we now simply append placeholder values rather than search and replacing a symbol (eradicates queryValuesSymbol and related hacks). If you manually issue queries through PgExecutor (extremely unlikely!) then you'll want to check out PR #270 to see the differences.

  • #260 d5312e6b9 Thanks @benjie! - TypeScript v5 is now required

  • #285 bd37be707 Thanks @benjie! - Single table inheritance no longer exposes non-shared columns via condition/order, and also only exposes the relationships on the types where they are appropriate.

  • #270 f8954fb17 Thanks @benjie! - EXPLAIN ANALYZE (for SELECT) and EXPLAIN (for other operations) support added. Currently requires DEBUG="datasource:pg:PgExecutor:explain" to be set. Publish this through all the way to Ruru.

  • #260 96b0bd14e Thanks @benjie! - PgSource has been renamed to PgResource, PgTypeCodec to PgCodec, PgEnumTypeCodec to PgEnumCodec, PgTypeColumn to PgCodecAttribute (and similar for related types/interfaces). source has been replaced by resource in various of the APIs where it relates to a PgResource.

    PgSourceBuilder is no more, instead being replaced with PgResourceOptions and being built into the final PgResource via the new makeRegistryBuilder/makeRegistry functions.

    build.input no longer contains the pgSources directly, instead build.input.pgRegistry.pgResources should be used.

    The new registry system also means that various of the hooks in the gather phase have been renamed/replaced, there's a new PgRegistryPlugin plugin in the default preset. The only plugin that uses the main method in the gather phase is now PgRegistryPlugin - if you are using the main function for Postgres-related behaviors you should consider moving your logic to hooks instead.

    Plugin ordering has changed and thus the shape of the final schema is likely to change (please use lexicographicSortSchema on your before/after schemas when comparing).

    Relationships are now from a codec to a resource, rather than from resource to resource, so all the relationship inflectors (singleRelation, singleRelationBackwards, _manyRelation, manyRelationConnection, manyRelationList) now accept different parameters ({registry, codec, relationName} instead of {source, relationaName}).

    Significant type overhaul, most generic types no longer require generics to be explicitly passed in many circumstances. PgSelectStep, PgSelectSingleStep, PgInsertStep, PgUpdateStep and PgDeleteStep now all accept the resource as their single type parameter rather than accepting the 4 generics they did previously. PgClassExpressionStep now accepts just a codec and a resource as generics. PgResource and PgCodec have gained a new TName extends string generic at the very front that is used by the registry system to massively improve continuity of the types through all the various APIs.

    Fixed various issues in schema exporting, and detect more potential issues/oversights automatically.

    Fixes an RBAC bug when using superuser role for introspection.

  • #271 d951897ee Thanks @benjie! - Add extensions.pg to Postgres function resources (makes it easier for plugins to hook them).

  • #270 c564825f3 Thanks @benjie! - set jit = 'off' replaced with set jit_optimize_above_cost = -1 so that JIT can still be used but heavy optimization costs are not incurred.

  • #286 366b166dc Thanks @benjie! - Add detection for @ref that is missing singular, fix docs and test schema and add tests for same.

  • #271 261eb520b Thanks @benjie! - 馃毃 RENAME ALL THE THINGS

    The term 'source' was overloaded, and 'configs' was too vague, and 'databaseName' was misleading, and 'source' behaviours actually applied to resources, and more. So, we've renamed lots of things as part of the API stabilization work. You're probably only affected by the first 2 bullet points.

    • pgConfigs -> pgServices (also applies to related pgConfig terms such as makePgConfig -> makePgService, MakePgConfigOptions -> MakePgServiceOptions, etc) - see your graphile.config.ts or equivalent file
    • All *:source:* behaviors are now *:resource:* behaviors (use regexp /:source\b|\bsource:[a-z$]/ to find the places that need updating)
    • PgDatabaseConfiguration -> PgServiceConfiguration
    • databaseName -> serviceName (because it's not the name of the database, it's the name of the pgServices (which was pgConfigs) entry)
    • PgResourceConfig::source -> PgResourceConfig.from ('source' is overloaded, so use a more direct term)
    • PgResource::source -> PgResource.from
    • PgSelectPlanJoin::source -> PgSelectPlanJoin.from
    • helpers.pgIntrospection.getDatabase -> helpers.pgIntrospection.getService
    • helpers.pgIntrospection.getExecutorForDatabase -> helpers.pgIntrospection.getExecutorForService

  • #266 395b4a2dd Thanks @benjie! - The Grafast step class 'execute' and 'stream' methods now have a new additional first argument count which indicates how many results they must return. This means we don't need to rely on the values[0].length trick to determine how many results to return, and thus we can pass through an empty tuple to steps that have no dependencies.

  • #268 a14cf5f4c Thanks @benjie! - PgV4NoIgnoreIndexesPlugin is now PgIndexBehaviorsPlugin, moved to graphile-build-pg, and is enabled by default

  • Updated dependencies [2df36c5a1, c5d89d705, a73f9c709, ae304b33c, 159735204, ef42d717c, d5312e6b9, 22ec50e36, 0f4709356, c22dcde7b, bd37be707, f8954fb17, 96b0bd14e, d951897ee, fbf1da26a, c564825f3, 366b166dc, 261eb520b, 395b4a2dd, a14cf5f4c, f6e644bd3]:

5.0.0-0.37

Patch Changes

5.0.0-0.36

Patch Changes

5.0.0-0.35

Patch Changes

5.0.0-0.34

Patch Changes

5.0.0-0.33

Patch Changes

5.0.0-0.32

Patch Changes

5.0.0-0.31

Patch Changes

  • #218 f2c1423fb Thanks @benjie! - Option for @foreignKey smart tag to have unique auto-created for it to ease transition from V4: { gather: { pgFakeConstraintsAutofixForeignKeyUniqueness: true } }

  • #219 b58f5dfac Thanks @benjie! - Rename GraphileBuild.GraphileBuildGatherOptions to GraphileBuild.GatherOptions. Rename GraphileBuild.GraphileBuildInflectionOptions to GraphileBuild.InflectionOptions.

  • Updated dependencies [f2c1423fb, b58f5dfac]:

5.0.0-0.30

Patch Changes

5.0.0-0.29

Patch Changes

5.0.0-0.28

Patch Changes

5.0.0-0.27

Patch Changes

5.0.0-0.26

Patch Changes

5.0.0-0.25

Patch Changes

  • 9a6b18fd9 - Give postgraphile() a named return type and export the V4 plugins from the V4 preset.

5.0.0-0.24

Patch Changes

5.0.0-0.23

Patch Changes

5.0.0-0.22

Patch Changes

5.0.0-0.21

Patch Changes

5.0.0-0.20

Patch Changes

  • 0ab95d0b1 - Update sponsors.

  • #196 af9bc38c8 Thanks @benjie! - Allow passing pool directly to makePgConfig.

  • #190 652cf1073 Thanks @benjie! - 馃毃 Breaking changes around types and postgres configuration:

    • GraphileBuild.GraphileResolverContext renamed to Grafast.Context
    • GraphileConfig.GraphQLRequestContext renamed to Grafast.RequestContext
    • Grafast.PgDatabaseAdaptorOptions renaed to GraphileConfig.PgDatabaseAdaptorOptions
    • @dataplan/pg/adaptors/node-postgres is now @dataplan/pg/adaptors/pg due to the bizarre naming of PostgreSQL clients on npm - we've decided to use the module name as the unique identifier
    • makePgConfigs:
      • is now makePgConfig (singular) - so you'll need to wrap it in an array where you use it
      • no longer exported by @dataplan/pg (because it depended on pg) - instead each adaptor exposes this helper - so import from @dataplan/pg/adaptors/node-postgres
      • accepts an object parameter containing {connectionString, schemas, superuserConnectionString}, rather than multiple string parameters
    • makeNodePostgresWithPgClient -> makePgAdaptorWithPgClient
    • postgraphile CLI will now try and respect the adaptor stated in your preset when overriding connection arguments
    • Removed Grafast.RequestContext.httpRequest and instead use Grafast.RequestContext.node.req/res; all server adaptors should implement this if appropriate

  • #192 80091a8e0 Thanks @benjie! - - Conflicts in pgConfigs (e.g. multiple sources using the same 'name') now detected and output

    • Fix defaults for pgSettingsKey and withPgClientKey based on config name
    • makePgConfig now allows passing pgSettings callback and pgSettingsForIntrospection config object
    • Multiple postgres sources now works nicely with multiple makePgConfig calls

  • Updated dependencies [0ab95d0b1, af9bc38c8, 4783bdd7c, 652cf1073, 752ec9c51, 80091a8e0]:

5.0.0-0.19

Patch Changes

  • 72bf5f535 - Overhaul the behavior system (see https://postgraphile.org/postgraphile/next/behavior).

    • Adds schema.defaultBehavior configuration option to save having to write a plugin for such a simple task
    • Changes a bunch of behavior strings:
      • (query|singularRelation|manyRelation|queryField|typeField):(list|connection|single) -> $1:source:$2 (e.g. query:list -> query:source:list)
    • Checks for more specific behaviors, e.g. source:update or constraint:source:update or attribute:update rather than just update
    • Updates every change to getBehavior so that it follows the relevant chain (e.g. codec -> source -> relation for relations, similar for other types)
    • More helpful error message when -insert prevents functions with input arguments working
    • Throw an error if you try and use "create" scope (because we use insert/update/delete not create/update/delete)

  • Updated dependencies [72bf5f535]:

5.0.0-0.18

Patch Changes

5.0.0-0.17

Patch Changes

5.0.0-0.16

Patch Changes

5.0.0-0.15

Patch Changes

5.0.0-0.14

Patch Changes

5.0.0-0.13

Patch Changes

5.0.0-0.12

Patch Changes

5.0.0-0.11

Patch Changes

5.0.0-0.10

Patch Changes

5.0.0-0.9

Patch Changes

5.0.0-0.8

Patch Changes

5.0.0-0.7

Patch Changes

5.0.0-0.6

Patch Changes

5.0.0-0.5

Patch Changes

5.0.0-0.4

Patch Changes

5.0.0-0.3

Patch Changes

5.0.0-0.2

Patch Changes

5.0.0-0.1

Patch Changes