Getting ready for V3

[goldcaddy77]

I've created a milestone for V3 here: https://github.com/goldcaddy77/warthog/milestone/1

I'd love to talk to folks that have used Warthog in Production to see what worked well for them and what they had to hack around. If you're interested in chatting, shoot me an email at [my github username] at gmail and we can set something up.

Working on documentation for the README here

Also, feel free to brainstorm ideas for V3 below.

[FOSSforlife]

I think it would be good to add Postgres 12 support (#304) to the V3 milestone, seeing as most people will want to use up-to-date database software. So far, I haven't had issues using Postgres 12, however I've only been doing basic tasks so far (mostly from your examples). Maybe we could define a series of tests to run that ensure it works?

[goldcaddy77]

@FOSSforlife early versions of PG12 failed because TypeORM was not compatible. If it’s compatible now, I can bump the version and everything should work. I should be able to do this in V2 since it wouldn’t be a breaking change.

[goldcaddy77]

I'm in the process of getting ready for 3.0. I've been working on it for a while in the beta branch. So far, I've added:

• Decorators for
  • PrimaryIdField
  • CreatedAtField
  • CreatedByField
  • DeletedAtField
  • DeletedByField
  • UpdatedAtField
  • UpdatedByField
  • VersionField
• New more flexible BaseModel and lightweight IdModel that uses the above decorators under the hood
• Sane Production defaults for all Warthog config values
• BaseService has been updated to not assume you use all Warthog "best practice" fields (createdAt, deletedAt, etc...)
• New config value: WARTHOG_DB_URL (allows setting all DB fields at the same time)
• Updates to SchemaGenerator to make output schema cleaner: (ex: ___WhereUniqueInput will not be generated if you don't have any unique fields, in a join table for example)
• Changes default behavior of Warthog to NOT filter or sort by default. You need to explicitly list which columns should be sort/filterable. Note: you can re-enable the old behavior by setting the WARTHOG_FILTER_BY_DEFAULT ENV var.

I'm planning on doing most of the items in the V3 milestone for the release. Is there anything else that you have noticed is missing that you've had to do yourself in your projects that wished was in Warthog itself?

@FOSSforlife / @diegonc / @metmirr / @bdombro / @domvernon / @nwmartin / @ikoenigsknecht / @tkvw / @popovserhii / @dzhelezov / @RileyMShea / @mknapik / @GrayStrider / @davidsielert / @bedeho / @IniZio / @7KAG7

[dzhelezov]

Hi, congrats on getting close to V3! Here are a few nice-to-haves that we had to work around ourselves while using warthog.

• Upgrade pg/pgtools lib. The current version makes warthog unworkable with Node 14 due to pg < 8 causes node 14+ to crash typeorm/typeorm#5949
• Make config more forgiving. We oftentimes import wathog-decorated model classes in external independent data loaders, and it's a bit awkward to set WARTHOG_* env variables just to be able to use the classes (as config() is picked up through the decorators and throws an error if the warthog env variables are not set). It would be nice (but not strictly necessary) to be able to pack the model classes into a lightweight dependency with only typeorm decorators.
• Making warthog fields optional is awesome! We were struggling with removing them from the model classes.
• The id field was for some reason excluded from the list of properties one can filter on, so it was hard to use semantically meaningful ids and use integer id types.
• Native support for long integers (ts type BigInt). It probably requires an opinionated choice of a suitable GraphQL scalar + numeric Postgres type.

[goldcaddy77]

@dzhelezov thanks for the feedback! Will take all of this into consideration. For the BigInt support, have you seen this example in the examples folder?

https://github.com/goldcaddy77/warthog/blob/main/examples/02-complex-example/src/modules/user/user.model.ts#L99-L100

It's not a first-class @bigint decorator, but simple enough.

[goldcaddy77]

Created tickets for your items:

• Make Config more forgiving #453
• Update libraries to provide support for Node 14 #451
• Native support for more specific types #454

Also: The id field was for some reason excluded from the list of properties one can filter on, so it was hard to use semantically meaningful ids and use integer id types is already fixed in V3.

[dzhelezov]

@dzhelezov thanks for the feedback! Will take all of this into consideration. For the BigInt support, have you seen this example in the examples folder?

https://github.com/goldcaddy77/warthog/blob/main/examples/02-complex-example/src/modules/user/user.model.ts#L99-L100

It's not a first-class @bigint decorator, but simple enough.

I should double-check but I think smth like

@IntField({ dataType: 'numeric', nullable: true })
bigIntField?: BigInt;

didn't work due to

• missing default transformers for typeorm
• GraphQL Int field being only 32-bit

We ended up doing this:

  @Field(() => GraphQLBigNumber)
  @WarthogField('numeric')
  @Column({ type: 'numeric', transformer: new NumericTransformer() })
  bigbigNumber!: BN

with some custom NumericTransformer and GraphQLBigNumber scalar

For the context: we sometimes have very large numbers (account balances) which may not even fit into 64 bits.

[dzhelezov]

I'm also curious if there are plans to support cross-relation filters as described by OpenCRUD https://www.opencrud.org/#sec-Cross-relation-filters ?

We rolled our own quick-and-dirty implementation but it's not very scalable atm.