https://www.prisma.io/ logo
Join SlackCommunities
Powered by
# prisma-client
  • d
    oh wow the story continues
  • c
    Is it possible to make all of these queries to the prisma DB in a single call versus doing this. Essentially I’d like to retrieve the fully populated 
    context.prisma.droneBuild({id: buildId})
    with all of it’s downstream parts in a single network request, rather than having to make 10 queries to retrieve that information.
    Copy code
    const flightController = await context.prisma.droneBuild({id: buildId}).flightController().flightController()
  const esc = await context.prisma.droneBuild({id: buildId}).esc().esc()
  const vtx = await context.prisma.droneBuild({id: buildId}).vtx().vtx()
  const receiver = await context.prisma.droneBuild({id: buildId}).receiver().receiver()
  const camera = await context.prisma.droneBuild({id: buildId}).camera().camera()
  const motor = await context.prisma.droneBuild({id: buildId}).motor().motor()
  const propeller = await context.prisma.droneBuild({id: buildId}).propeller().propeller()
  const frame = await context.prisma.droneBuild({id: buildId}).frame().frame()
  const antenna = await context.prisma.droneBuild({id: buildId}).antenna().antenna()
  const battery = await context.prisma.droneBuild({id: buildId}).battery().battery()
  • f
    Hi, I have this model
    Copy code
    type Poi {
  id: ID! @id
  title: String!
  address: PoiAddress
}

type PoiAddress {
  id: ID! @id
  address1: String
  address2: String
  zipcode: String
  country: String
}
    Now I want all Poi's wich don't have an address. I tried
    Copy code
    prisma.pois({
            where : {
                address : {
                    country: null
                }
            }
        });
    But that gave me an empty response. Any ideas?
  • n
    So, I'm seeing some weird lag when fetching relations on a deeply-nested query. If I have a datamodel that looks like:
    Copy code
    type Content {
  name: String
  children: [Content!]! @relation(link: TABLE, name: "ContentChildren")
}
    Then I do a query to my GraphQL API with more than two levels of nesting, e.g.:
    Copy code
    {
  content(id: $id) {
    children {
      name
      children {
        name
        children {
          name
          children {
            name
          }
        }
      }
    }
  }
}
    And in my 
    children
    resolver, I call 
    prisma.content({ id }).children()
    , I see response times that look like this: • first level: ~30ms • second level: ~30ms • third level: ~200ms • fourth level: ~700ms
  • n
    Does anyone know what would cause that exponential slowdown? I've tried putting all the calls to 
    prisma
    behind a dataloader, and I've tried memoizing individual calls, but both approaches seem to just be papering over the underlying problem
  • n
    I got those timings from Apollo, so they encompass more than that single field in my real data model, but you can still see an exponential slowdown on that specific relation the deeper into the query you go
  • n
    and I can't figure out why, since 
    prisma.thing({ id }).relationToOtherThing()
    should take the same amount of time no matter where that 
    thing
    is in the original query, no?
  • n
    By the by, I think it might be related to https://github.com/prisma/prisma/issues/4744 ?
  • n
    ok, I’m still trying to figure out what the deal with, but I think prisma is chocking on cyclic graphs
  • n
    even if I’m not asking it for any cycles at any one time
  • n
    e.g. if I have Content and Tags, I might do Content.tags -> Tag or Tag.assignedTo -> Content
  • n
    so if I get a single graphql request (for Content) with 
    { tags { assignedTo { id } } }
    that generates these prisma calls in my resolvers: • 
    prisma.contents({ id }).tags()
    • 
    prisma.tags({ id }).assignedTo()
  • n
    and that is causing prisma to choke, even though I’m not technically asking for a cycle in any one request
  • a
    Hi there 👋 I just asked a question in #prisma2-preview accidentally about prisma1:
    Hi, I'm working with prisma1 and wondering how one would do something similar to a SQL 
    join
    using the generated client (edited)
    With a [response](https://prisma.slack.com/archives/CKQTGR6T0/p1578044014242700?thread_ts=1578043823.242500&cid=CKQTGR6T0)
    you can fetch related data either using the Prisma client's fluent API or using the 
    $fragment
    API: https://www.prisma.io/docs/prisma-client/basic-data-access/reading-data-TYPESCRIPT-rsc3/#relations
    However, this doesn't allow me to join on a collection. Why is this? This is possible with the $fragment, why not in the fluent API?
  • a
    Also, what I actually want is to get items where the related item (1:1) has a prop with a certain condition
  • r
    Is it correct way to write 
    orderBy
    in prisma client ?
    👍 1
  • m
    hi @everyone! I’ve messed up and set up a type named Subscription in the datamodel, now Subscriptions don’t work (obv). How to migrate the existing subscription data to another type?
  • l
    anyone know how to use delegrate schema with prisma-client? just like something below in prisma-bindling:
    Copy code
    @Query('post')
  async getPost(@Args() args, @Info() info): Promise<Post> {
    return <http://this.prisma.query.post|this.prisma.query.post>(args, info);
  }
    here is a issue: https://github.com/prisma/prisma/issues/3103
  • m
    Just started with Prisma client and exploring it's capabilities. One of the first things I tested was to see if the queries generated by Prisma are optimal and I was surprised a bit. E.g. :
  • m
    Copy code
    async function main() {

  const allPosts = await prisma.post.findMany({
    include: { author: true },
  })
  console.dir(allPosts, { depth: null })
}
  • m
    I would expect this to be a single query, e.g. a FETCH JOIN in other ORM tools. But to my surprise it did this:
    Copy code
    prisma:query SELECT `dev`.`Post`.`id`, `dev`.`Post`.`title`, `dev`.`Post`.`content`, `dev`.`Post`.`published`, `dev`.`Post`.`authorId` FROM `dev`.`Post` WHERE 1=1 LIMIT ? OFFSET ?

prisma:query SELECT `dev`.`User`.`id`, `dev`.`User`.`email`, `dev`.`User`.`name` FROM `dev`.`User` WHERE `dev`.`User`.`id` IN (?) LIMIT ? OFFSET ?

[
  {
    id: 1,
    title: 'Hello World',
    content: null,
    published: false,
    authorId: 2,
    author: { id: 2, email: <mailto:'maria@prisma.io|'maria@prisma.io>', name: 'Maria' }
  }
]
    n
    • 2
    • 3
  • m
    So it seems to execute an additional query for each Post to get the Author resulting in a N+1 problem which will punish performance.
  • m
    Is this expected behaviour with Prisma or can I tweak this somehow?
  • m
    (note I'm using Prisma Client 2.0 beta)
  • m
    Not true what I'm saying, I just see it now
  • m
    It will probably not be a N+1 issue but simply 2 queries as it uses a IN
    s
    • 2
    • 1
  • m
    So when using multiple levels of includes it will use an additional query per level then I guess...
  • m
    ==== Another question, does Prisma Client support something like application wide caching or is that maybe something for the roadmap? Or is it recommended to implement caching independent of the Prisma Client. Coming from a Java world using Hibernate, Hibernate has something like second-level caching which is able to cache often used data. E.g. country data, reference data or perhaps from the previous example all author data.
    n
    • 2
    • 3
  • l
    Heyyy 👋 Someone able to help me with some prisma client stuff? more precisely about crud operations on many to many relationships?
  • a
    hello! trying to use prisma.create to seed a new record into database, which has JSON. Getting an error on the JSON entry, anyone know if prisma client supports JSON that was released in beta4?
1...456...23Latest