Hi @revolter,
I have mixed feelings about this change. I assume your use case is that you have several database files in subdirectories, and a single .env file applicable to all of them in the parent directory or in the project root. But what happens if we load in memory a .env file which wasn't for us and contains other secrets. I guess nothing very important, besides failing to open the database, but it put us in a risky situation.

At least, I think this behaviour should be opt-in through a setting in the preferences' dialog.

Hi @mgrojo,

I assume your use case is that you have several database files in subdirectories, and a single .env file applicable to all of them in the parent directory or in the project root.

Ish. I have some encrypted databases in an iOS app, and running it in the Simulator places the databases in a deeply nested location under ~/Library, and it also changes on every subsequent run. As such, I want to place the .env file in the root folder to be picked up regardless.

But what happens if we load in memory a .env file which wasn't for us and contains other secrets.

True, good catch!

I now realize that other tools with a similar feature have their own custom naming for these files (they're also configs, not secret holders).

At least, I think this behaviour should be opt-in through a setting in the preferences' dialog.

Makes sense!

But, with the above, what do you think of searching for .db4s.env outside the current folder, and for .env OR .db4s.env? This way, whenever you see a dotenv file with NO database next to it, you know what's it about, we don't risk clashes with other software, and we could deprecate the non-specific file name in the future.

While I understand the use case here as well, I do not think that this is the right approach. Especially with deeply nested file hierarchies, this is some unnecessary overhead, apart from the fact that at some level the permissions might not even be available anymore.

For this use case, it seems like letting the environment load the .env file into environment variables and allowing DB4S to read them (I am not sure whether this might already be supported) seems like the most straightforward approach where each user can choose the preferred way to achieve the loading.