Stephen Haberman
Stephen Haberman
cc @chr1sjf0x for other ideas
@chr1sjf0x ah yeah, in this instance it is to avoid 3 round trips; we can't issue the queries simultaneously b/c the `IN` in the 2nd query depends on the result...
Filed https://github.com/stephenh/joist-ts/issues/240
Ah yes! It is definitely simpler, which is why it's been implemented that way so far. :-D That said, if you meant "simpler" as in simplicity that means "the database...
Am I correct that this is about the follow bug: ``` scala case class Foo(m1: Map[String, Int], m2: Map[String, Seq[String]]) val kryo = new KryoReflectionFactorySupport() KryoSerializer.registerCollectionSerializers(kryo) ScalaTupleSerialization.register(kryo) val foo1 =...
@sritchie Thanks! I am a Kryo newbie so couldn't tell if this was a Chill bug or an underlying issue in Kryo (given that long thread about references). Oddly enough,...
@hoangvvo do you have any numbers about how much faster `slow-json-stringify` was specifically for your project or on a graphql-jit benchmark? Just thinking that, per your wondering if a PR...
Fwiw my strawman proposal would be to allow `?` or `!` on the key itself, i.e. (mapping GraphQL types to TypeScript types out of laziness/but it still express semantics well):...
Following up on my strawman proposal, if making a breaking change was acceptable, it'd be simpler to change the semantics of `firstName: String!` to mean "key is optional, value is...
Hey, just curious why you're wanting to avoid the default methods? Just wondering if you have a lesson learned I could pick up.