https://www.prisma.io/ logo
Join SlackCommunities
Powered by
# orm-help
  • a
    I've working on a food order platform and I would like to query all the added dishes (cartitems) inside a customers cart from a given restaurant. My datamodel looks like this: 
    type Customer {
    id: ID! @id
    createdAt: DateTime! @createdAt
    updatedAt: DateTime! @updatedAt
    name: String
    email: String
    phone: String
    user: User
    cart: [CartItem]!
    orders: [Order]!
    }
    type CartItem {
    id: ID! @id
    quantity: Int! @default(value: 1)
    dish: Dish!
    customer: Customer!
    }
    type Dish {
    id: ID! @id
    name: String!
    price: Float!
    description: String!
    isAvailable: Boolean! @default(value: true)
    category: String
    restaurant: Restaurant!
    }
    type Restaurant {
    id: ID! @id
    createdAt: DateTime! @createdAt
    updatedAt: DateTime! @updatedAt
    user: User
    name: String!
    street: String!
    number: String !
    addition: String
    zip: String!
    city: String!
    dishes: [Dish]!
    orders: [Order]!
    }
    I can query the data inside the playground area with the following query 
    query {
    customer(where: { id: "ck8zwslgs00da0712cq88e3oh" } ) {
    id
    cart(where: { dish: { restaurant: { id: "ck904gwl400mz0712v0azegm3" } } }) {
    quantity
    dish {
    name
    price
    restaurant {
    id
    name
    }
    }
    }
    }
    }
    But I can't figure out how to do this nested filter with the prisma client. Tried some things 
    const data = await ctx.db.query.customer({
    where: {
    AND: [
    {
    id: args.customerID
    },
    {
    cart: {
    dish : {
    restaurant: {
    id: args.restaurantID
    }
    }
    }
    }
    ]
    }
    }, info);
    const data = await ctx.db.query.customer({
    where: {
    id: args.customerID
    cart: {
    dish : {
    restaurant: {
    id: args.restaurantID
    }
    }
    }
    }
    }, info);
    const data = await ctx.db.query.customer({
    where: {
    id: args.customerID
    },
    cart: {
    where: {
    dish : {
    restaurant: {
    id: args.restaurantID
    }
    }
    }
    }
    }, info);
    const data = await ctx.db.query.customer({
    where: {
    id: args.customerID
    },
    cart: {
    dish : {
    restaurant: {
    where: {
    id: args.restaurantID
    }
    }
    }
    }
    }, info);
    The first one returns an error "Field \"cart\" is not defined by type CustomerWhereUniqueInput". The last two are returning every cartItem from the customer. Someone can help me out with this?
  • a
    @Anthony Magnus I am quite new to prisma as well but don't you need to use connect to connect to the id or any unique field of the types you are using?
  • a
    Hi @Amin For what I know about Prisma, the connect functionality is only for mutations and not for queries. Correct me if I'm wrong.
    • 1
    • 1
  • c
    Hey guys is anyone using Prisma 1.34 in production? We are getting an ambiguity error and we are worried that when we make our next change we won't be able to update production without nuking the DB
  • e
    What is the error?
  • c
    Copy code
    ERROR: There is a relation ambiguity during the migration. Please first name the old relation on your schema. The ambiguity is on a relation between Portfolio and User. Please name relations or change the schema in steps.

{
  "data": {
    "deploy": null
  },
  "errors": [
    {
      "locations": [
        {
          "line": 2,
          "column": 9
        }
      ],
      "path": [
        "deploy"
      ],
      "code": 3018,
      "message": "There is a relation ambiguity during the migration. Please first name the old relation on your schema. The ambiguity is on a relation between Portfolio and User. Please name relations or change the schema in steps.",
      "requestId": "local:ck91xed3700bz0853u0gb4tfq"
    }
  ],
  "status": 200
}
  • e
    Just sounds like instead of doing something like
    Copy code
    type Portfolio {
  user: User
}
    you’ll need to name the relation
  • e
    Copy code
    type Portfolio {
  user: User! @relation(name: "PortfolioToUser", onDelete: CASCADE)
}
  • e
    something like that?
  • c
    I will send the data model, one second its different to that. It is possibly to do with having 2 types of user on the type
  • c
    Copy code
    type Portfolio { 
id: ID! @id 
name: String! 
description: String! 
seedCurrency: Currency! 
seedBalance: Float! 
cashBalance: Float! 
founder: User! @relation(name: "PortfolioToUser") 
patrons: [User] @relation(name: "PatronsToPortfolios", onDelete: SET_NULL) 
microFunds: [MicroFund!]! @relation(name: "MicroFundToPortfolio") 
snapShots: [SnapShot!]! @relation(name: "SnapShotToPortfolio") 
createdAt: DateTime! @createdAt 
updatedAt: DateTime! @updatedAt 
}
    Copy code
    type User { 
id: ID! @id 
createdAt: DateTime! @createdAt 
updatedAt: DateTime! @updatedAt 
username: String! @unique 
email: String! @unique 
password: String! 
status: UserAccountStatus! privileges: [Privilege!]! @scalarList(strategy: RELATION) portfolios: [Portfolio!]! @relation(name: "PortfolioToUser") 
patronisedPortfolios: [Portfolio] @relation(name: "PatronsToPortfolios", onDelete: SET_NULL) # @default(value: NULL) 
transactions: [StockTransaction!]! @relation(name: "TransactionToUser") 
fundUpdates: [FundUpdate!]! @relation(name: "UpdateAuthorToMicroFund") 
}
  • e
    Copy code
    patrons: [User!]!
  • c
    Doing that still has the same outcome it seems
  • e
    Huh, interesting
  • c
    We were just trying that too to see
  • c
    We are not in a position to delete our DB as our product is in market
  • e
    you shouldn’t need to, but you named the relations. Did you use the same name on the inverse relationships?
  • e
    one example from our db is like
    Copy code
    sentDMs: [DirectMessage!]! @relation(name: "UserSentDMs", onDelete: CASCADE)
  • c
    yes we always use the same relationship name for both sides of the relation
  • e
    Copy code
    sender: User! @relation(name: "UserSentDMs", link: TABLE, onDelete: SET_NULL)
  • c
    do we need to be explicit around the link?
  • e
    I don’t think so
  • e
    and definitely don’t use link: table if you ever want to move to something else like hasura (which i recommend)
  • e
    prisma 1.34 doesn’t scale at all
  • c
    What is your recommendation?
  • c
    Move on to a new solution?
  • e
    Do you use subscriptions a lot, or just basic query and mutation operations?
  • c
    Currently we are using mutations and queries
  • c
    Our plan was to take advantage of subscriptions in the future
  • e
    The subscription system is not implemented well and it’s not implemented at all in 2
1...364365366...637Latest