My dev DB lives on Heroku, so it's a remote DB, not locally-hosted
My dev DB lives on Heroku, so it's a remote DB, not locally-hosted
Mcan you file a feature request for that? https://github.com/cloudflare/workers-sdk/issues/new?assignees=&labels=enhancement&projects=&template=feature-request.yaml&title=%F0%9F%9A%80+Feature+Request%3A
MYou don’t need to manage the pool in the client. Further, because Workers are typically short lived, your “pool” wouldn’t last any longer than your Worker invocation. Hyperdrive’s pooling is much, much more robust.
SLetsgoooo, finally! Thanks team
MWill do.
MGreat! Thanks.
MIs it possible to load one TOML in local dev and another for live? I'm aware that the TOML files supports environments, but I'm trying to circumvent this issue. Guess not if the file must be named exactly ?
Myou can pass a path to the config file
MCreate, develop, and deploy your Cloudflare Workers with Wrangler commands.
MAh, interesting
MHi again. My Worker needs to access multiple DBs. Can I set up multiple Hyperdrives under one worker, and how would I model/reference these in the TOML file?
KJust repeat the [[hyperdrive]] block
MRight - and then assign a different value to each param within it, and reference those in my JS to denote which DB to connect to, right?
MWhen running my worker on CF, for endpoints that talk to Hyperdrive I get an error if I refresh the page soon after getting a response. This seems to happen only for routes that talk to HD, not ones that output a simple, static response. The error is: Any idea what that might be about?
KDo you have code that reproduces the error?
KIt sounds like you have I/O happening outside of the (or other handlers).
MIt seems (thanks to @PurpleBlob ) I was reusuing a DB client. I'm in the process of adapting my app from Express.js use, and hadn't properly changed this part to create a DB client on a per-request basis. So all fixed. Thanks anyway.
JI can't wait to try this!
Phey guys - is there a clear docu about localconnectionstring? when i run the worker in local mode it tells me i need to add one - does this string has to be fully text, or can i use env variables in it as well? I really dont like to put passwords in the code.
KIt’s just a string.
Phmm... so now i have it configured exactly like in the example, but when i launch wrangler dev --remote it tells me Unexpected fields found in top-level field: "hyperdrive"
KWhat version is Wrangler?
Pfigured it out - if you never deployed your worker, then its not working. you need to deploy it once to the server, and then the dev --remote works
CYou should log out and back in so wrangler can update its permissions as the message says.
KDo you have a Workers Paid plan?
KYeah, you need a paid plan for Hyperdrive.
SIs it possible to leave ideas for the Hyperdrive dashboard here? If so, it would be great to add a small (readable) name/description to each Hyperdrive. This will make it more clear for what the Hyperdrive connection is being used. Thanks
MAlways feel free to leave feature requests/feedback here 
SWhat is more recommended while using Hyperdrive?
Opening a connection w/ a query:
Or just simply using Pooling?
Opening a connection w/ a query:
Or just simply using Pooling?
K is fine
KHyperdrive will manage a pool of connections for you.
SI'm getting the following without opening a connection: Error: The script will never generate a response.
KDo you have code to reproduce it?
KThat usually means you're doing stuff in the global scope, which is a no-go in Workers.
SI think I know what I'm doing wrong lmao. I'm developing locally, so it's in no way connected through Hyperdrive. So I need to open the connection first 
SOk that's not the reason, it's not working in production either. Creating a thread to paste the code. (Sorry for tagging: @kian)
MI have an issue which may or not be related to @Sam's. I've set up a Hyperdrive, but when I run locally, I get an error from PG that , even though I'm connecting to a publicly-accessible (albeit remotely-hosted) DB. Other apps on my local machine not using CF can connect to it fine, as can a local DB client I use. The connection string is definitely correct. If I run the app with it does connect. Anyone any idea here?
SIt's not related to mine, the "HYPERDRIVE" environment variable is not being filled developing locally. You need to do this yourself
MNot sure I follow. My TOML has:
MShouldn't that work locally? The guide suggests that's what's needed.
SAh yeah, I'm using another way by putting it in my .dev.vars. Don't want my connection string exposed in the wrangler.toml file. But still not related to my issue 
MAhh OK, gotcha. Re: not exposing the connection string, I faced the same issue. I found that if I put my connection string in my Wrangler error'd on startup, it had to be in the TOML. So in the end I set up two TOMLs - and and just pointed my dev script to the latter via the arg.
MAnyway, good luck with your issue. Hopefully someone from CF (@kian?) can help with the above as it's proving a pain!
KI’m just a community member but I agree that it’s a bit of an odd pattern, the traditional guidance is that everything in Wrangler.toml is safe to commit to VCS & secrets are either stored on the edge or in .dev.vars