Closed wereHamster closed 2 years ago
This would be awesome. My current use case:
union AccessNode = Story | Document
type AccessList {
id: ID!
createdAt: DateTime!
updatedAt: DateTime!
collaborators: [User!]! @relation(name: "CollaboratorOnAccessList")
spectators: [User!]! @relation(name: "AccessListOnUser")
node: AccessNode
}
It should be pretty self-explanatory, but the gist is that I'd like to use the AccessList
to control access to different types of entities without having several relations (like in the example above having a story
and document
relation field.
I can identify these use cases for union types, are there more?
Yes! Unions and interfaces would definitely rock!
I have a similar usecase as altschuler, where I want to create Blogposts, who have a content that is a list of several contentElement types such as Text, Quote, Image, Map, ...
see also https://github.com/graphcool/feature-requests/issues/83
Another use case: sorting against several different types that are related in an external context.
My use case: I have a Person
type; a user can create Note
s about the person; when the user sends the person a message it also logs an Interaction
. I'd like to union Timeline = Note | Interaction
and query against it with the usual sorting and pagination techniques.
@marktani do you have any color on the likelihood of this getting implemented?
This will likely be pushed out together with interface types #83. However, there's no clear timeline yet. Thanks for your feedback everyone π
Great to hear. Will it be released to beta users initially?
On Fri, Aug 25, 2017 at 05:00 Nilan Marktanner notifications@github.com wrote:
This will likely be pushed out together with interface types #83 https://github.com/graphcool/feature-requests/issues/83. However, there's no clear timeline yet. Thanks for your feedback everyone π
β You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/graphcool/feature-requests/issues/165#issuecomment-324899000, or mute the thread https://github.com/notifications/unsubscribe-auth/AAneTGnj6c8lcM_icd-wleRd-78CsvMPks5sbrd1gaJpZM4M5qPz .
Here's a concrete example for union queries if that helps.
We have 3 tables, all which have different data, but in a particular screen, they need to be sorted across all three and paginated together.
type Announcement implements Node {
...etc...
title: String!
associatedDate: DateTime!
}
type Event implements Node {
...etc...
title: String!
associatedDate: DateTime!
}
type Conversation implements Node {
...etc...
name: String!
responseRequiredBy: DateTime!
}
In SQL we could just union the things and give them a unified structure, then ORDER BY whatever we called the date filed. In graph.cool right now we've created another record that relates to all 3 so we can execute this query, but it'd be much nicer to construct this with a view rather than by needing an actual new node that denormalises the data in order to feed what shows in one screen while the rest of the nodes are actually quite distinct.
I use union types for every product category as they possess different properties.
union Product = Shoes | Dress | TShirt | Suit | ...
Without union types or interfaces I can't make a type Order
as the list may contain only values of one particular type:
type Order {
...
products: [Product!]! @relation(name: "ProductsInOrder")
...
}
It also helps if with union types you'll introduce a @relation
directive which can be used with all types of the union or interface:
type Shoes {
...
orders: [Order!]! @relation(name: "ProductsInOrder")
...
}
type Dress {
...
orders: [Order!]! @relation(name: "ProductsInOrder")
...
}
type TShirt {
...
orders: [Order!]! @relation(name: "ProductsInOrder")
...
}
type Suit {
...
orders: [Order!]! @relation(name: "ProductsInOrder")
...
}
Are there any chances it'll be included in 1.0? @marktani
Also hoping for support of unions in the near future!
Any news on union/interface types?
We are planning to add support for interfaces in the near future. We haven't started the implementation work yet, so it is too early to give a concrete timeline. Does interfaces as described in https://github.com/graphcool/prisma/issues/83 solve all your use cases?
Yes, but my team also shares many of the use cases described in this thread for union types, specifically https://github.com/graphcool/prisma/issues/165#issuecomment-336125858
+1
Suggesting a workaround for this at https://medium.com/@tibotiber/graphql-interfaces-and-union-types-with-prisma-and-yoga-7224f9e1d9ad. Happy to get any feedback.
+1
How about support for unions on enums
enum BaseballType {
SOFTBALL_PITCH
EXIT_VELOCITY
INFIELDER_GLOVE_TO_GLOVE
CATCHER_POP_TIME
HOME_TO_FIRST_RUN
FIVE_TEN_FIVE
TWENTY_YARD_DASH
FORTY_YARD_DASH
SIXTY_YARD_DASH
NONE
}
enum BasketballType {
FREE_THROW_RELEASE_ANGLE
INBOUND_TIME
REBOUND_HEIGHT
JUMP_HEIGHT
WINGSPAN
FULL_COURT_RUN
NONE
}
union HighlightType = BaseballType | BasketballType
+1 this would be really helpful
+1 I would love to see this implemented !
@marktani Has there been any progress on this?
I have just published a spec that touches on this topic. We would love to hear your feedback on this one.
I just realized that you can't even write things as simple as
type Process {
events: [Event!]!
}
union Event = Message | Completion
type Message {
message: String!
}
type Completion {
exitCode: Int!
}
Because prisma complains:
$ prisma deploy
Deploying service `kumo` to stage `dev` to server `prisma-us1` 50ms
Errors:
Process
β The field `events` has the type `[Event!]!` but there's no type or enum declaration with that name.
Deployment canceled. Please fix the above errors to continue deploying.
Read more about deployment errors here: https://bit.ly/prisma-force-flag
@samuela - I'm curious if you already took a look at the spec posted by @mavilein above. It describes how we intend to implement polymorphic relations based on interfaces and union types. It would be helpful if you could let us know if this design would satisfy your needs. Thanks!
Out of curiosity, why downvotes on my previous comment?
@sorenbs Thanks for sending along the spec! I wasn't aware of that. I just came across this thread after a bit of googling.
Overall, the spec looks decent and I think it would satisfy our use case. Ultimately all that I really want are algebraic data types. I don't need interfaces and unions. I just want a clean way to represent algebraic data types. In graphql/prisma that seems to be via unions. In terms of the specifics, I'm a bit confused why @discriminator
is introduced. Prisma could easily handle this automatically without burdening the user.
@samuela : Prisma will handle it without burdening the user. The spec says that the @discriminator
directive is optional. We have the directive in there because we want to also support existing databases that will likely diverge from our defaults for mapping to the database.
Hey @mavilein, Been waiting on this for quite a while, so happy to see some movement. Do you have any idea when we could expect this? π
Hi, I was wondering if there are any updates on this ?
On scale of 1 to 10, how much progress were made? 1= not even started, 10=completed
Same use-case as https://github.com/prisma/prisma/issues/165#issuecomment-306051926 Am using Prisma to create Pages which contain an array of components for composing a page:
type Page {
url: String
components: [Carousel | Text | GridList | Accordion]
}
Current workaround looks like:
type Page {
url: String
orderings: [String]
carousels: [Carousel]
texts: [Text]
gridLists: [GridList]
accordions: [Accordion]
}
with orderings being a list of global IDs for placing them in order on the page. Then we manually stitch them back together after retrieval:
page.components = [
...page.carousels,
...page.texts,
...page.gridLists,
...page.accordions,
].sort((a, b) => {
const posA = page.orderings.indexOf(a.id);
const posB = page.orderings.indexOf(b.id);
return posA - posB;
});
Any progress here?
Any news on union types? :)
Desperate for union types hereππ»ββοΈ
...
While I'm also looking forward to union types I think the Prisma team has been hard at work on a lot of neat things recently (well... the last few years...) so I hope it comes soon but thanks for all the hard work π
If we think about how union types would actually be implemented by Prisma things get complicated quickly. We can't assume a particular database technology will have native facilities for union types. Does Prisma create a new underlying type for each union it encounters? Does that get mapped to its own entity in the database (e.g. a new table)? There are a lot of ways union types could be implemented and a lot of tradeoffs. At least to me this seems like a harder problem than it appears to be.
Interfaces and Union would be a great benefit as described in the spec above. How is this update coming along in 2020?
http://graphql.org/learn/schema/#union-types
http://graphql.org/graphql-js/type/#graphqluniontype
https://medium.com/the-graphqlhub/graphql-tour-interfaces-and-unions-7dd5be35de0d