profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/hlship/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Howard M. Lewis Ship hlship @walmartlabs Portland, OR, USA http://lewisship.net/ I sling Clojure code at Walmart.

AvisoNovate/pretty 494

Library for helping print things prettily, in Clojure - ANSI fonts, formatted exceptions

hlship/cascade 159

Simple, fast, easy web applications in idiomatic Clojure.

AvisoNovate/rook 74

Smart namespace-driven routing for Pedestal

AvisoNovate/config 72

Configure a system using EDN files and clojure.spec

AvisoNovate/twixt 45

An extensible Clojure library for serving web application assets

hlship/boardgamegeek-graphql-proxy 28

A demo GraphQL application that exposes parts of the BoardGameGeek XML API

clj-commons/vizdeps 26

Visualize Leiningen dependencies using Graphviz

AvisoNovate/logging 22

Easy setup of clojure.tools.logging w/ SLF4j, plus request correlation

AvisoNovate/taxi-toolkit 17

A Clojure library designed to help with writing integration tests using clj-webdriver.

hlship/bootstrap-examples 9

Examples of Twitter Bootstrap

issue closedwalmartlabs/lacinia

Boolean defaults in parsed schema are parsed as `:True`/`:False` rather than `true`/`false`

When a schema is parsed that contains a Boolean with a default, this is parsed into a Lacinia EDN schema as :True or :False rather than true or false.

This can be verified with the followig

(schema-parser/parse-schema "schema {
  query: Query
}

type Query {
  example(in: Boolean = False) : Boolean
  anotherExample(in: Boolean = True) : Boolean
}")

which produces:

{:roots {:query :Query},
 :objects
 {:Query
  {:fields
   {:example
    {:type Boolean,
     :args {:in {:type Boolean, :default-value :False}}},
    :anotherExample
    {:type Boolean,
     :args {:in {:type Boolean, :default-value :True}}}}}}}

This results in associated resolvers getting the keywords :True or :False if nothing was provided and true/false otherwise.

This issue seems to suggest that it would be appropriate to parse this to true/false.

closed time in 2 days

markgdawson

issue commentwalmartlabs/lacinia

Boolean defaults in parsed schema are parsed as `:True`/`:False` rather than `true`/`false`

This is not a bug. Boolean values are true and false; the capitalization is what triggers the incorrect behavior.

(schema-parser/parse-schema "schema {
  query: Query
}

type Query {
  example(in: Boolean = false) : Boolean
  anotherExample(in: Boolean = true) : Boolean
}")
=>
{:roots {:query :Query},
 :objects {:Query {:fields {:example {:type Boolean, :args {:in {:type Boolean, :default-value false}}},
                            :anotherExample {:type Boolean, :args {:in {:type Boolean, :default-value true}}}}}}}

Also see the spec.

markgdawson

comment created time in 2 days

push eventwalmartlabs/lacinia

Howard Lewis Ship

commit sha 06b06490a6dec4150591b4f3b7ab5567144c35c3

Update documentation

view details

Howard Lewis Ship

commit sha 2812c267705facb3b8cc31f469f1c97720cae039

Properly report fragment definition referencing unknown type

view details

Howard Lewis Ship

commit sha 30c2d9a6b90f160a0ce32a136514116802f20248

Remove temporary code

view details

Howard M. Lewis Ship

commit sha 2c10696a96425f7620b3c1646039015f84d4c285

Merge pull request #379 from walmartlabs/hls/354-identify-type-for-fragment-error Correct NPE when fragment definition references unknown type, and properly report the error

view details

push time in 2 days

push eventwalmartlabs/lacinia

Howard Lewis Ship

commit sha 30c2d9a6b90f160a0ce32a136514116802f20248

Remove temporary code

view details

push time in 2 days

issue closedwalmartlabs/lacinia

[0.38.0] When the type condition of a fragment references an unknown type, the error message is not so useful

An example where I used an invalid type name in my query document:

{:errors
   [{:message
     "Cannot query field `isAmendInProgress' on type UNKNOWN.",
     :locations [{:line 18, :column 28}],
     :extensions {:field-name "isAmendInProgress", :type-name nil}}]}

My query document mistakenly had on OnlineGroup when the correct type name is OrderGroup; OnlineGroup should replace UNKNOWN in the error message.

closed time in 2 days

hlship

push eventwalmartlabs/lacinia

Howard Lewis Ship

commit sha 2812c267705facb3b8cc31f469f1c97720cae039

Properly report fragment definition referencing unknown type

view details

push time in 2 days

push eventwalmartlabs/lacinia-pedestal

atsfour

commit sha c246928a49a48bc3a2e3fabf24db6fa0c5875462

Downgrade. "subscriptions-transport-ws" to "0.8.3"

view details

Howard M. Lewis Ship

commit sha 889ff66179f89a6737b9f27261668f947951e550

Merge pull request #118 from atsfour/fix-version-subscriptions-transport-ws Fixed "subscriptionsClient.subscribe is not a function"

view details

push time in 6 days

PR merged walmartlabs/lacinia-pedestal

Fixed "subscriptionsClient.subscribe is not a function" bug dependencies

Start the server with the following command with the current package configuration, execute the following query at localhost: 8888 / ui

subscription Tick {
   ticks {
     count
   }
}

The following error occurs

{
   "message": "subscriptionsClient.subscribe is not a function",
   "stack": "TypeError: subscriptionsClient.subscribe is not a function \ n at Object.subscribe (http: // localhost: 8888 / assets / graphiql / graphiql-subscriptions-fetcher-browser-client.js: 8734: 64) \ n at http: // localhost: 8888 / assets / graphiql / graphiql.min.js: 1:553273 "
}

To fix this, change the version of "subscriptions-transport-ws" to "0.8.x".

Since "subscriptions-transport-ws" is not well maintained, it is better to use "graphql-ws" instead.

https://github.com/enisdenjo/graphql-ws

+242 -52

1 comment

2 changed files

atsfour

pr closed time in 6 days

create barnchwalmartlabs/lacinia

branch : hls/354-identify-type-for-fragment-error

created branch time in 8 days

issue commentcandid82/joker

Exceptions from :parse-fn w/ joker.tools.cli are not caught

I'll work on a PR for this.

hlship

comment created time in 8 days

issue commentcandid82/joker

Exceptions from :parse-fn w/ joker.tools.cli are not caught

Note that:

hlship

comment created time in 8 days

issue openedcandid82/joker

Exceptions from :parse-fn w/ joker.tools.cli are not caught

Calls to the parse-fn option are supposed to be wrapped such that exceptions are promotted into parse errors; that either isn't happening, or the strack trace of the thrown exception is becoming the error message.

Welcome to joker v0.17.2. Use '(exit)', EOF (Ctrl-D), or SIGINT (Ctrl-C) to exit.
user=> (require '[joker.tools.cli :as cli])
nil
user=> (cli/parse-opts ["-P" "3.2"] [["-P" "--para N" :parse-fn joker.strconv/atoi]])
{:options {}, :arguments [], :summary "  -P, --para N", :errors ["Error while parsing option \"-P 3.2\": <joker.tools.cli>:228:28: Eval error: strconv.Atoi: parsing \"3.2\": invalid syntax\nStacktrace:\n  global <repl>:3:1\n  joker.tools.cli/parse-opts <joker.tools.cli>:545:23\n  joker.tools.cli/parse-option-tokens <joker.tools.cli>:271:9\n  core/reduce <joker.core>:702:17\n  f <joker.tools.cli>:274:35\n  joker.tools.cli/parse-optarg <joker.tools.cli>:248:9\n  joker.tools.cli/parse-value <joker.tools.cli>:228:28"]}

created time in 8 days

push eventwalmartlabs/lacinia

Howard Lewis Ship

commit sha 2e53b9d19ba758d9773b03e08d4784c3ce7d15d3

Hack around perms issue with JDK 16

view details

push time in 8 days

push eventwalmartlabs/apidocs

Howard Lewis Ship

commit sha dd61fab3fa31fe8d01e3f75c42f4802f14167dfe

com.walmartlabs/lacinia 0.39-alpha-10

view details

push time in 8 days

push eventwalmartlabs/lacinia

Howard Lewis Ship

commit sha 22f8548ca5e68b8c16e265e998c875bad92f963b

Prep for 0.39-alpha-10

view details

push time in 8 days

push eventwalmartlabs/lacinia

Howard Lewis Ship

commit sha db541552f7b2d48714347787998cf49aacd979ed

Add test for failure condition

view details

Howard Lewis Ship

commit sha 350de0b97808a8633795ae0daa629644dcaf89dd

Fix NPE caused by mix of dynamic and literal field args

view details

Howard Lewis Ship

commit sha 9d2412245c6191a229f3245cc97cff7ffa9929e7

Test args passed to resolver

view details

Howard M. Lewis Ship

commit sha c0870e8c0c3537aede93aa6c711291ffc5a3695e

Merge pull request #377 from walmartlabs/hls/365-npe-dynamic-arg Fix NPE related to mix of literal and dynamic values in an input object

view details

push time in 8 days

issue closedwalmartlabs/lacinia

NullPointerException when processing dynamic argument

We use filters on collections that can be composed recursively via boolean logic. In the example below the or field takes an array of StringFilters. When the array contains a StringFilter with a constant ("blue") and another one with a dynamic argument ($color) the query execution returns an error. The NPE seems to occur at https://github.com/walmartlabs/lacinia/blob/v0.38.0/src/com/walmartlabs/lacinia/parser.clj#L637 when literal-values is {:color {:equals "blue"}} and dynamic-extractor is nil.

Setup

com.walmartlabs/lacinia {:mvn/version "0.38.0"}
(require '[com.walmartlabs.lacinia.schema :as schema]
         '[com.walmartlabs.lacinia.util :as util]
         '[com.walmartlabs.lacinia :as lacinia])

(let [schema (-> '{:queries
                   {:cars {:type :CarCollection
                           :args {:filter {:type :CarCollectionFilter}}
                           :resolve :get-cars}}
                   
                   :input-objects
                   {:CarCollectionFilter
                    {:fields {:or {:type (list :CarCollectionFilter)}
                              :color {:type :StringFilter}}}
                    
                    :StringFilter
                    {:fields {:equals {:type String}}}}
                   
                   :objects
                   {:Car
                    {:fields {:color {:type String}}}
                    
                    :CarCollection
                    {:fields {:nodes {:type (list :Car)}}}}}
                 (util/attach-resolvers {:get-cars (fn [context args value]
                                                     {:nodes []})})
                 (schema/compile))
      query "query($color: String) {
               cars(filter: {or: [{color: {equals: \"blue\"}},
                                  {color: {equals: $color}}]}) {
                 nodes {
                   color
                 }
               }
             }"
      args {:color "red"}]
  (lacinia/execute schema query args nil))

Expected result

{:data #ordered/map ([:cars #ordered/map ([:nodes ()])])}

Actual result

{:errors [{:message "java.lang.NullPointerException"}]}

closed time in 8 days

lxbr

push eventwalmartlabs/lacinia

Howard Lewis Ship

commit sha 9d2412245c6191a229f3245cc97cff7ffa9929e7

Test args passed to resolver

view details

push time in 8 days

create barnchwalmartlabs/lacinia

branch : hls/365-npe-dynamic-arg

created branch time in 8 days

issue commentwalmartlabs/lacinia

NullPointerException when processing dynamic argument

Taking a step away helps and the solution was pretty obvious once I looked into it carefully.

lxbr

comment created time in 8 days

issue commentwalmartlabs/lacinia

NullPointerException when processing dynamic argument

I'm looking into this; seems like a dynamic arguments extractor is ending up as nil when it shouldn't; might be related to the heavy recursion in your input fields, but it should still work.

lxbr

comment created time in 16 days

issue closedwalmartlabs/lacinia

Incorrect null `non-null` field error handling

The GraphQL spec has that if a field is non-nullable and null is returned for it, the null should "bubble up" to the next nullable parent (i.e., the parent should be returned as null). This allows for clients that expect non-nullable fields (e.g., skip null checks).

From the spec:

"If the field which experienced an error was declared as Non-Null, the null result will bubble up to the next nullable field. In that case, the path for the error should include the full path to the result field where the error occurred, even if that field is not present in the response."

found here: http://spec.graphql.org/June2018/#sec-Errors

closed time in 16 days

solussd

push eventwalmartlabs/lacinia

seeday

commit sha 850adc35edce87f58e81dc4b21e4c725ca4f870b

Add bigint/bigdec support

view details

seeday

commit sha 213744eef8033fc6dbbbb93fa34aee7bfaf639f1

Add some more tests

view details

Howard M. Lewis Ship

commit sha 61371f488b394e794442a932ce002ad26e7eeb53

Merge pull request #375 from seeday/master Add BigInt/BigInteger/BigDecimal support to int and float serialization

view details

push time in 16 days

PullRequestReviewEvent