Solve some of the array of custom type issues #92
Conversation
|
(The tests are failing because some of the schema tests only expose schema |
|
Oh. My. Gosh. So this took a bit to solve. Issue relates to getting types/classes from private schemas when they're required indirectly by items in the public schema (e.g. where a column is an array of a private type). At first I tried rewriting our introspection query, but doing so turned out to be much more complex than I first anticipated (would have required a recursive CTE to pull in extra types at each level if they were required by the previous one). Then I tried just expanding what the introspection query gives us, but that of course caused conflicts due to a poor architecture decision I made early on. So I thought, why not filter it to just the required parts in the introspection query; but of course this would only work with default plugins and would make it harder for others to extend the system. In the end I decided to correct my architectural decision - types are no longer defined eagerly ahead of time, instead you register a generator and then you call the generator when you need the type. (Even this turned out to be more complex than expected!) This could all do with a serious refactor, but being short on time as I am we'll have to make do for now and refactor for v5. On the plus side, this should avoid a number of the issues we were getting where types in private schemas that aren't ultimately exported were clashing with types in the public schema. |
| rel.relnamespace in (select "id" from namespace) or | ||
| rel.reltype in (select "returnTypeId" from procedure) or | ||
| rel.reltype in (select unnest("argTypeIds") from procedure) | ||
| ) and |
There was a problem hiding this comment.
This was the crux of the issue, making this filter broad enough was a real challenge. Instead I removed it and perform on-demand type definition rather than eagerly creating all the classes.
|
wow @benjie so this is what you've been up to! Great work! |
|
thanks @benjie looking forward to using this ASAP! |
|
It's in the latest release of postgraphql@next/postgraphile - let me know if it works 👍 |
|
looks like a lot great work! From what I reviewed, looks good :) If I'm correct, graphile-build-pg is still querying all the types on server via psql, however, types don't leave the server to the client unless they are used in the schema that is being explicitly requested. Solid work!!! Thanks again @benjie |
|
Yeah, they effectively spider out from the tables/functions/views in the exposed schemas. By the way more integration tests would be welcome if there’s certain ways you’re using the system and you want to ensure they aren’t subtly changed without good cause. |
Fixes #83