DataProxy Client logging is different from normal logging
See original GitHub issueDataProxy Client:
C:\Users\Jan\Documents\throwaway\3.12.0_simple>npx ts-node scripts.ts
prisma:query query {
findManyFoo {
id
name
}
}
prisma:info Schema (re)uploaded (hash: 11e52bd7ecad95f9f3809fd9d8fec1533840f048c3c245ce8b703d8ff19d2fb3)
prisma:info Calling https://aws-us-east-1.prisma-data.com/3.12.0/11e52bd7ecad95f9f3809fd9d8fec1533840f048c3c245ce8b703d8ff19d2fb3/graphql (n=0)
id
name
}
}
prisma:info Calling https://aws-us-east-1.prisma-data.com/3.12.0/11e52bd7ecad95f9f3809fd9d8fec1533840f048c3c245ce8b703d8ff19d2fb3/graphql (n=0)
foo proxy [ { id: '624c5afcef6abe4179942612', name: 'foo' } ]
Normal library
Client:
prisma:client:libraryEngine Searching for Query Engine Library in C:\Users\Jan\Documents\throwaway\3.12.0_simple\.prisma\client +53ms
prisma:client:libraryEngine Searching for Query Engine Library in C:\Users\Jan\Documents\throwaway\3.12.0_simple\prisma\library +0ms
prisma:client:libraryEngine loadEngine using C:\Users\Jan\Documents\throwaway\3.12.0_simple\prisma\library\query_engine-windows.dll.node +1ms
prisma:client Prisma Client call: +920ms
prisma:client prisma.foo.findMany({}) +2ms
prisma:client Generated request: +0ms
prisma:client query {
prisma:client findManyFoo {
prisma:client id
prisma:client name
prisma:client }
prisma:client }
prisma:client +1ms
prisma:client:libraryEngine sending request, this.libraryStarted: false +871ms
prisma:client:libraryEngine library starting +1ms
prisma:client:libraryEngine library started +43ms
prisma:query db.Foo.aggregate([ { $project: { _id: 1, name: 1, }, }, ])
foo library [ { id: '624c5afcef6abe4179942612', name: 'foo' } ]
prisma:client:libraryEngine library stopping +675ms
prisma:client:libraryEngine library stopped +2ms
prisma:client:libraryEngine hookProcess received: beforeExit +1ms
prisma:client:libraryEngine runBeforeExit +1ms
prisma:client:libraryEngine hookProcess received: exit +1ms
While it is expected that the DataProxy client can not log the query that is executed right now, there is no reason why e.g. “Prisma Client call” should not also be logged the same way it is with the normal Client.
Issue Analytics
- State:
- Created a year ago
- Comments:6 (6 by maintainers)
Top Results From Across the Web
Configuring logging (Concepts) - Prisma
Learn how to configure Prisma Client to log the raw SQL queries it sends to the database and other information.
Read more >Configure Grafana | Grafana documentation
Grafana needs a database to store users and dashboards (and other things). ... [dataproxy]. logging. This enables data proxy logging, default is false...
Read more >Set Up Client Logging | LiveSwitch Cloud Documentation
You can hook into the logging API if you want to know what's happening in your client app. ... Error: A normal app...
Read more >Logging HOWTO — Python 3.11.1 documentation
logging.warning() if there is nothing the client application can do about the situation, ... Another common way is to write them to a...
Read more >A Complete Guide to Logging in Go with Zerolog - Better Stack
Zerolog is a high-performance Go structured logging library aimed at ... WARN , and ERROR levels while other levels are logged normally.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Oh, I see, so there are two different kinds of logs we’re talking about here, I was thinking about the
DEBUG
env var given the library client output, but there’s also thelog
argument to the Prisma Client constructor.I cloned your reproduction repo, and this is what I got:
Library:
Notice that most of the logs you posted are missing, which is expected given just the configuration in your repo, I didn’t set the
DEBUG
env var in addition to that since I’d already tested that with 3.12 and 4.0.Data Proxy:
Thus, we can now see two distinct problems here:
prisma:query
logs differ. Normal client prints the actual SQL or MongoDB query here, but the Data Proxy prints the GraphQL query to the engine because it doesn’t have a way to know the raw query. This looks intentional, as SQL logging is not implemented for the Data Proxy yet.DEBUG
env var logs don’t work for the edge Data Proxy client (though they do now work with regular Node.js Data Proxy client in Prisma 4). This might or might not be expected, but we can probably make it work if it makes sense (at the very least it could be specified at generation time whether to inject theDEBUG
env var and enable the debug logs or not).Re-checked this again.
With Prisma 3.12.0 no logs whatsoever with
DEBUG=*
on my system, not even those that @janpio posted.With Prisma 4.0.0 and node runtime everything works fine, the same logs as I posted above.
With Prisma 4.0.0 and edge runtime (which I didn’t think about last time), no logs again. If I pass
{ __internal: { debug: true } }
to the constructor instead of using the env var, the edge client crashes: