Prisma1: Error on prisma generate: ; expected on switching to prisma datamodel v1.1

[devautor]

Describe the bug
Getting error on prisma generate with datamodel v1.1
I had posted this to forum three days ago, and it's still not resolved. It's most probably related to empty many-to-many table generation. Error trace:

  CustomerWishlistsRelation (Relation)
  + Created an inline relation between `Customer` and `CustomerWishlist` in the column `customer` of table `CustomerWishlist`

Applying changes 4.1s
Generating schema 61ms
 !    ';' expected. (185:8)
 !      183 | export type PostsProductsRelationOrderByInput =
 !      184 |
 !    > 185 | export type WishlistedProductsRelationOrderByInput =
 !
 !          |        ^
 !      186 |
 !      187 | export type MutationType =   'CREATED' |
 !      188 |   'UPDATED' |

Get in touch if you need help: https://spectrum.chat/prisma
To get more detailed output, run $ export DEBUG="*"

Your Prisma endpoint is live:

To Reproduce
I have pushed a reproduction on github here: https://github.com/devautor/prisma-link-beta-bug-repro/tree/master
Steps to reproduce the behavior:

1. Clone
2. prisma generate
3. See error

Expected behavior
Prisma generate should do magic, not errors! (An empty folder is of no use tbh)

Versions (please complete the following information):

• Connector: Prisma Demo Cloud + MySQL
• Prisma Server: [e.g. 1.32.0-beta]
• prisma CLI: prisma/1.32.0-beta (windows-x64) node-v8.11.3
• OS: Windows 10

Additional context
As posted in forum, I had to use @scalarList(strategy: RELATION) on fields with scalar lists being [String!]! and [Int!]! to fix the very (first) original error.

[pantharshit00]

I can confirm this. ~Related to the generation of types for the relational strategy for scalarLists as input would be nothing for a primitive but the cli is somehow trying to generate the input.~ Nope, just tried a more minimal repro and scalarLists are fine when RELATION is used.

I have opened a new issue regarding the defaults in scalarList here: https://github.com/prisma/prisma/issues/4426

[pantharshit00]

Found a workaround, remove the relationTable for now(they will be implicitly created).

So the bug is related to type generation for link table. They should be ignored.

[cramhead]

I think I have a similar issue, but have existing data. It doesn't seem reasonable to ignore when there's data there.

[pantharshit00]

@cramhead

By ignore, I mean we don't need to generate types for link tables(no use in the client). Sorry if I was not explicit

[devautor]

@pantharshit00 Got it, going to try the same, i.e. not defining a relation table explicitly. I'd like some clarification on what am I losing then (I mean, prisma has a design, there must be some reasoning behind it).
Docs say that implicitly this is created for a many-to-many relationship:

CREATE TABLE "default$default"."_MyRelation" (
  "post" varchar(25) NOT NULL,
  "category" varchar(25) NOT NULL
);

And, when using @relationTable explicitly, this is created:

CREATE TABLE "default$default"."MyRelation" (
    "post" varchar(25) NOT NULL,
    "cagtegory" varchar(25) NOT NULL
);

1. What's the difference between the two designs?
2. I think both of these give me names "post" and "category" instead of "A" and "B". Does it matter in prisma generate by any means (I have no idea since never saw one generated with datamodel 1.1)?

Thanks :)

[pantharshit00]

1. There is no difference other than you can customize the table name

2. Sometimes you need to name stuff differently, that is why we have that option. Somehow we have not implementation handling of the directive in the client

[divyenduz]

This is a bug in Prisma CLI's JS schema generation, it is not in sync with the actual Prisma API anymore. A workaround is implemented as described here: https://github.com/prisma/prisma/issues/3184

When the Prisma server endpoint is live, we can use: prisma generate --endpoint to use the live endpoint directly and bypass the JS based schema generation.

We would fix the JS schema generation part shortly.

[devautor]

Hello @divyenduz I was trying to use the solution that you had provided, with the difference that I had deployed prisma server to fargate in the meantime using this tutorial.

Having changed the datamodel, I am getting this error when deploying with prisma deploy -e .env (after I have done prisma reset -e .env successfully):

Applying changes 1.0s
 !    The Migration failed and has not been performed. This is very likely not a transient issue.
 !    java.sql.SQLException: (conn=3763) Cannot drop index 'PostsCollectionsRelation_AB_unique': needed in a foreign key constraint

What is being messed by me here?

EDIT: This same error occurs even deploying after prisma delete --force -e .env.

[devautor]

I can safely use this in prisma 1.33. I am closing this w.r.t. my issue's responsibility.

[macrozone]

this bug still ocures in 1.34.10. Is there a fix?

@devautor as you closed this issue, can you explain how to fix it? It seems be related to nested @embedded types. any idea?

[cramhead]

I don't have time to try this right now, but I'm wondering if specifying the specifying the databaseType in the prisma.yml would solve the problem, like in https://github.com/prisma/prisma/issues/4578

[macrozone]

@cramhead indeed this fixes the issue!