Prefixing an entity with Prisma field type leads to an incorrect schema

[sohelzerdoumi]

When generating Prisma schema from Wasp entities, the reserved words for field type, collide with entity name. This results in incorrect Prisma schema output.

The following reserved words lead to incorrect replacement: String, Boolean, Int, BigInt, Float, Decimal, DateTime, Json, and Bytes

Example:

The following Wasp entity definition uses the reserved word Int as a prefix for an entity name Internet:

entity User {=psl
  id                        Int                  @id @default(autoincrement())
  // other...
  internets Internet[]       
psl=}

entity Internet {=psl
  id                        Int             @id @default(autoincrement())
  user                      User            @relation(fields: [userId], references: [id])
  userId                    Int
psl=}

The generated Prisma schema output is incorrect:

model User {
  id Int @id @default(autoincrement())
  internets Int
  auth Auth?

}
model Internet {
  id Int @id @default(autoincrement())
  user User @relation(fields: [userId], references: [id])
  userId Int

}

The expected output should be:

model User {
  id Int @id @default(autoincrement())
  internets Internet[]
  auth Auth?

}
model Internet {
  id Int @id @default(autoincrement())
  user User @relation(fields: [userId], references: [id])
  userId Int

}

Steps to reproduce:

1. Create a Wasp entity definition file with a reserved word prefix (e.g. Int) for an entity name.
2. Create a relation
3. Run the Prisma schema generation command.
4. Verify that the generated Prisma schema output is incorrect due to the reserved word prefix not being replaced.

Expected behavior: The reserved word prefix should be replaced with a valid entity name.

Probable issue location

wasp/waspc/src/Wasp/AppSpec/Entity/Field.hs

Line 64 in 7658064

pslFieldTypeToScalar fType = case fType of

[sodic]

Thanks for reporting @sohelzerdoumi. This is a significant bug.

Nice work!

[Martinsos]

Oh wow! This is a bug in our PSL parser -> I probably forgot to check for "end of word" when matching those keywords. Shouldn't be too hard to fix, a bit of parsec magic and we should be good!

[sodic]

@Martinsos The "end of word" rule possibly wouldn't solve it.

Not sure how Prisma handles this, but if PSL has different namespaces for type space and value space like most languages do, we'd need something more elaborate.

For example, if Prisma allows entities to be named Int, end-of-word wouldn't help us :)

[Martinsos]

@Martinsos The "end of word" rule possibly wouldn't solve it.

Not sure how Prisma handles this, but if PSL has different namespaces for type space and value space like most languages do, we'd need something more elaborate.

For example, if Prisma allows entities to be named Int, end-of-word wouldn't help us :)

INteresting point, but I doubt it, how would it differentiate between their Int and custom Int then? PSL is quite simple, so position is important, and at that position it always expects a type space name, not value space name. So I don't think this is an issue, it indeed should only be just "end of word". I am 98% confident in this.

[infomiho]

This will be fixed by this commit 1b1753a#diff-55352e979a392d702b404e0a168abbf61a0c26527248deee8ea77055287e9626R85

Background: there is a reserved parser which does exactly what we need:

The lexeme parser reserved name parses symbol name, but it also checks that the name is not a prefix of a valid identifier. A reserved word is treated as a single token using try.