prisma1

prisma1 copied to clipboard

It would be nice to have it on the data store level.

@marktani Just thinking, if I have two (relation) fields, and I want the combination to be unique, would it be possible to concatenate the two id's in a TRANSFORM_ARGUMENT RP into a field on the Type that has a unique constraint? And enforce the unique constraint on the combination like that? It's a lot easier than PQ's...

This is a feature that is already supported by every conventional SQL backend, it would be great to be able to specify it with an annotation or similar.

Please see proposed spec: https://github.com/graphcool/framework/issues/1300 I'd love your input, especially on the syntax.

This would be very nice to have in prisma, are there any plans?

Yes, a possible specification is being considered + discussed in detail here: https://github.com/graphcool/prisma/issues/1300

@marktani is there an update on where we are at with this?

This is related to #3405. Additionally we should consider the following:

• [ ] Ordering by multi-column indexes
• [ ] Generated API schema (especially the generated where input types)

Bumping this one up! About to write a weird hack because I'm saving API responses which are only uniquely identified by a combination of data points which I also need saved separately. Writing my own unique checkers feels sad after using also this slick autogenerated magic.

this is sorely needed feature. i have to build all of these useless primary keys for linking tables representing many-to-many relationships.

I agree that I miss this feature too.

Chiming in to also request this feature. Seems like a no brainer to support many existing schemas.

This is a common case that I encounter on my 1st hello world case. Looking fwd it.

please where are with this, any luck

+1

+1

@nicovalencia @ahmedfouzan @vidrepar Please don't comment +1 and give the issue a thumbs up 👍 instead. It's really annoying for everybody who has subscribed to this issue.

There is a workaround. Please check this answer https://stackoverflow.com/a/56984957/4578951 Give a thumbs up if you like this workaround 👍

I have an issue with existing DBs which already have composite keys. It would be so much easier if Prisma could just use them.

+1 to support composite/compound primary keys, almost any existing db uses them in m:n relations

After a few days convincing the dev team to move forward with prisma, I spent a couple days actually implementing this. Only to discover that composite unique (which is a crucia requirement for our project), is not supported by prisma. Its very frustrating to have to throw away all that wasted work and go back to the drawing board because one missing feature, which was reported 3 years ago, makes this library unusable. I wish I could've used prisma, other than missing feature, it seems really awesome.

Hey Jontroncoso, To handle this problem I just added a new field to the table named ID with an auto-incriminating Int. I also set it as a unique and as an index. Then I introspect the DB and assign the the ID as the ID, works perfectly.

@blazestudios23 I'm trying to understand your solution, but not quite getting it. Do you mind elaborating?

Are you saying that you created an ID column on your table manually in your database? If so, I don't understand how that fixes the issue of composite keys.

@counterbeing Yes, it's a work around for example if you have a composite key of name + address, but no actual ID. I just added an ID column, set it as a unique index and as an auto-incrementing int. I then set this field as @id in Prisma. I set name and address as strings. This works perfectly.

It's actually a very simple and easy solution, that takes a few minutes to implement.

Would be really nice, especially for upserts deinfed by multiple pieces of data.