The path name of the pocketbase executable is tied to the database

[IwateKyle]

The problem below seems to be resolved. But I really struggled with this for about 30 minutes. Then all of the sudden, I was getting the expected results. I'll leave this discussion here in case anyone else was having the same experience. Otherwise if someone wants to close it - okay.

===============================================================================
Is there a reason why the database is directly tied to the user facing executable name.

Where pb_data is the same location, all the below try to create a new database upon first access.

• pocketbase serve
• ~/bin/pocketbase serve
• ~/bin/myapp serve

This makes it difficult to

• move to production where the path is not necessarily the same as development
• change the name of the executable after database has been created
• move the executable to a new location without jumping through hoops using aliases and softlinks.

It seems that if there were some reason to have multiple databases created in the same pb_data folder, then a command line option should be used to address which database is intended to be accessed, not the name of the executable.

Is there a work-around. I have already created data, but the path will not work for me in production. How can I change the hard linked path in the database?

[ganigeorgiev]

I don't understand what do you mean. The executable name has nothing to do with the database name.

You can rename the executable however you want.

pb_data by default will be created next to the executable. If you want to specify a different pb_data location, you can make use of the --dir flag:

./pocketbase serve --dir="/path/to/your/pb_data_dir"

You can list all available flags with --help.

[mdnahas]

I have a similar question/issue. pocketbase read/writes its files in relationship to the location of the binary, not the current working directory.

When I run "../pocketbase serve", it creates directories "pb_data" and "pb_migrations" in the parent directory (where the binary is located) and not in the current directory.

That feels wrong.

[ganigeorgiev]

@mdnahas You can explicitly set custom pb_data and pb_migrations directories with the --dir and --migrationsDir flags to accommodate your use case.

[mdnahas]

@ganigeorgiev Yes, I know that. I'm saying that almost every other program operates in the directory where they are run, not the location of the binary. PocketBase's current behavior is the unexpected. It is breaking convention. You should only break convention if you think there's a huge win, and I don't think see it here.

Right now, I'm learning pocketbase and making a lot of demo directories. I don't want to copy the binary into each one. I don't want to do the lengthy "--dir demo4/pb_data --migrationDir demo4/pb_migrations ..." every time I invoke pocketbase.

My current solution is to do symbolic links to the binary in each demo directory. That seems to work. I hate using symbolic links this way, but it works.

But more than anything, pocketbase is breaking convention. Which means its users will keep stumbling into this problem, like I did. Please have it match the convention (or give me a very good reason for it to break the convention!).

[ganigeorgiev]

@mdnahas I don't understand what do you refer by convention. It is just an implementation detail.

The main idea behind the current defaults is that the binary usually should stay together with your project files (or at least that's how I'm planning to use it). You can have multiple projects and each can use different PocketBase version and/or configurations.

PocketBase is distributed as a regular Go package and you can use it as a library as part of your own Go program. The current prebuilt executable is just a simple example created from the examples/base/main.go file. You can always create your own if you don't like the current defaults.

At the end of the day, this is just a small hobby open source project that I've created primarily for my own needs (see Presentator #183) and I'm not trying to sell you anything. If you find it useful - great! If not - there are plenty of other more mature solutions maintained by larger teams that can provide better support and more features (just to mention some - Supabase, Nhost, Appwrite, SurrealDB, EdgeDB, Strapi, Directus, etc.)

[mdnahas]

@ganigeorgiev By "convention", I mean "every other program runs this way". E.g., "ls", "cat", etc.. It is easier to learn a program if it behaves like every other program.

It is a great project! I'm coding a small site for a friend's small business. I may not be around to maintain it, so I wanted something simple that he could understand and keep working. And now, having used PocketBase a little, I plan on using it a lot. I've been programming my whole life and I've had an iPhone for 13 years that I've never programmed for --- I can easily whip up a fun program for it in a few days with PocketBase!

BTW, I found out about it on HackerNews. When someone asked what backend to use, someone said it was the only one that made backends fun to program. I understand why they said that!

It's your own project, so do what you like. But you can expect other users to run into this problem, because it diverges from the convention.