graphql-engine
graphql-engine copied to clipboard
hasura
better support for postgres array/hstore types
Currently the input for an array is a literal, i.e for a column of type text[] the input value has to be a string as follows: "{hello,world}". We should do the appropriate mapping to json arrays.
This works when the literal is typed out in the body of the query, but I can't even get the string syntax to work when the value is passed in as a variable.
Actually, turns out that variables work as long as their type is _text and not String.
We should also be supporting the common operators on arrays like we did for json/jsonb.
Till we add this, as a workaround, you can use JSONB and store JSON encoded arrays. We have a support for a bunch of operators including some that have contains type functionality.
On Sun, 3 Feb 2019 at 7:32 AM, Syed Jafri [email protected] wrote:
Most importantly, would like to see _contains support on arrays
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/hasura/graphql-engine/issues/348#issuecomment-460016048, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIAWA9mqDzYSsvacwZ-bZUkajdJFSHOks5vJkMcgaJpZM4WXXKh .
@coco98 I have seen the @> contains support for JSONB, the problem is that primitive arrays provide statistics, and are thus more efficient in queries.
I use this a lot with Rails https://edgeguides.rubyonrails.org/active_record_postgresql.html#array
Is there an update on this. it's getting really hard updating the arrays, no mapping... we always need to do some hacks to accomplish those simple operations.
Hi @yassinebridi, https://github.com/hasura/graphql-engine/pull/2243 had to be aborted to handle some edge cases. We'll be picking this up again in a couple of weeks.
What can we do for now instead... without resorting to implementing custom server just to have a single endpoint for this exact query?
If there's none, then I guess that's how it should be.
fyi just knowing that the right format for text[] is {hello,world} solved my problem (obvious in retrospect) — consider adding it to docs
@JorgeCeja This issue is for server. Suppose for array types in console is here: https://github.com/hasura/graphql-engine/issues/2544
Any update on how we can use array and what will be the type of field for it in hasura? https://hasura.io/docs/1.0/graphql/manual/mutations/insert.html#insert-an-object-with-an-array-field This is not working and sending back as string and also there is no text[] or _text in field types in hasura.
Is it possible or planned to have the _contains filter type for arrays? Arrays seem to work in general but not for filtering.
@JorgeCeja , @AkshayCloudAnalogy .. there's a way to "access" the text[] through the console (I know, it's a hack 😅)
Here's a gif showing how:
- you can write the "[]" symbol after selecting the "text" type
I migrated a column from jsonb to text[], defined __text: string[] in codegen.yml and generated typescript types. The type of queried data was cool, but I found out I can't insert arrays to the field because the data should be in this array literal format... Looking forward to this issue being addressed.
@rtrembecky Not sure I understand "data should be in this array literal." Is the reason the array can't be updated due to something with Hasura or the client library you use to talk to Hasura (I use React Apollo, for example)? Were you able to format the data in a way that you could update the arrray?
@danstepanov this was nearly a year ago, so I don't remember well, but I believe this is a problem of Hasura - when you use text[] as a field format, you receive the data as an array, but you need to insert/update data in "array literal format" instead - "{hello,world}" as mentioned by OP here. this would require somehow migrating all arrays in mutations to this format.
my goal was to make the typescript types better and be more confident in our code (not to introduce clutter), so I decided to stick to jsonb and to hope this gets solved (and we see it never did).
Got it, thanks @rtrembecky.
The way I have gotten around this is passing in the variable as:
variables: { stringArray: `{ ${newArrayItem} }` }
within useMutation. And my actual query type definition is:
gql`
mutation MyMutation(
$stringArray: _text
) {
REST_OF_MUTATION_HERE...
}
This is definitely bonkers and I haven't yet set it up for if you want to keep the old values of stringArray and simply add one more item to it. But it works for now. Btw, in Hasura, my data type for stringArray is text[].
This is kind of bonkers, indeed. I wonder why arrays are second class citizens in hasura and what the decision making was behind that. The fact that JSONb operators work for this use case seems like more of an accident than an intended workaround.
Having proper support for arrays would be great. Kinda sucks that it still isn't supported even though this issue is from 2018
