I have existing schema for prisma.
I copied the table from another schema to be included in the Prisma schema.
But when I run prisma db pull new table doesn't appear in Prisma schema.
Why?
If you use supabase and running this command and it returns something like this 'The following models were commented out because we couldn't retrieve columns for them. Please check your privileges.' or something similar regarding privileges, the solution is to go to your SQL editor from supabase and put this command and execute it
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO postgres;
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO postgres;
You're misinterpreting the function of the prisma db pull command.
From the docs
The db pull command connects to your database and adds Prisma models to your Prisma schema that reflect the current database schema.
Basically, it will make your Prisma schema match the existing database schema. What you want is the opposite here: Update the database schema to match the current Prisma schema.
You can do this in two ways:
If you want to update the database and keep the changes in your migration history, use the prisma migrate dev command. More Info
If you just want to update the database without creating a migration, use the prisma db push command. More info
More information is available in the docs explaining how you should choose between 1 and 2.
I had a similar issue once and a quick check confirmed for me that it was the lack of security permissions granted for prisma on new table in the database itself.
Try this:
Note the name of the database user that Prisma connects to the database with. You'll likely find this via your schema.prisma file, or perhaps via a DATABASE_URL config setting in the related .env file if you're using that with prisma.
Go into the database itself and ensure that database user which Prisma connects with has been granted sufficient security privileges to that new table. (note: what 'sufficient' is I cannot say since it depends on your own needs. At a guess, I'd say at least 'select' permission would be needed.)
Once you've ensure that user has sufficient privileges, try running a prisma db pull command once again.
For reference, another thing you could do is:
cross-check against one of the other tables that is already in your database that works correctly with prisma.
compare the security privileges of that old table with the security privileges of the new table and see if there are any differences.
Related
I've been working on maintenance on this GitHub repo that has been left undeveloped for almost a year. When rerunning the GitHub Actions job that finished to completion last May, there are now issues related to permission for CREATE in the public schema in PostgreSQL. At first I suspected, this might be because of the recent PostgreSQL 15 update that made it so that users do not by default have create access on the public schema. However, for our job GitHub Actions uses Postgres 14 for Ubuntu 22.04 (postgresql_14+238), so this change to public schema access in PostgreSQL shouldn't be affecting us. Our previous passing run used Postgres 12 for Ubuntu 20.04 (postgresql-12_12.10-0ubuntu0.20.04.1), so the changed environment could still be relevant.
The job is erroring out during a step where we create a few tables within our database using <user>:
peewee.ProgrammingError: permission denied for schema public
LINE 1: CREATE TABLE IF NOT EXISTS "articles" ("id" INTEGER NOT NULL...
Before this step, we configure the PostgreSQL database, creating the <user> and granting it all permissions to the database: `
CREATE USER <user>;
GRANT ALL PRIVILEGES ON DATABASE <db_name> to <user>
To remedy this problem (while still being confused on why it arose), I tried to explicitly grant <user> permissions on the public schema before attempting any CREATEs following the suggestions from this post: https://www.cybertec-postgresql.com/en/error-permission-denied-schema-public/
GRANT ALL ON SCHEMA public TO <name>;
which seems to go through based on the returned GRANT .
Locally, I'm having no issues with permissions even without the GRANT using PostgreSQL 14, but the permission error still comes up on GitHub Actions, even after granting access to the public schema to the user (and in a desperate attempt--to all users).
I've done a bunch of sanity checks related to making sure that we are in fact using the <user> during the CREATE step, but it seems like the <user> just never ends up getting the permissions even after the GRANT. I followed postgresql - view schema privileges to view schema privileges, and locally, the <user> has permissions to the public schema even before the GRANT. However, on GitHub Actions, the <user> doesn't have permissions before nor after the GRANT, even though there is output confirmation that the GRANT completed successfully.
Does anyone know why I would be having these permission errors now on GitHub Actions, despite the code working locally and on GitHub Actions months ago? Is there any way I can grant permissions differently that might work better in this environment?
The permissions on schema public changed in v15. This change finally got rid of the insecure default setting of letting every user create objects in that schema. Now only the database owner is allowed to create objects by default.
Your GRANT statement is good to allow a user to create objects in schema public:
GRANT CREATE ON SCHEMA public TO user_that_creates_objects;
Just remember that you have to connect to the target database before running that statement. Also, the GRANT must be executed by the database owner or a superuser.
My recommendation is to leave the public schema for extension objects and create your own schema for your application objects.
I am using PostgreSQL as my database along with Prisma as my ORM.It seems to be giving an issue while running the 'prisma migrate' command on the server which seems to be an issue of user database privileges not being present.What are the basic user privileges that are required for Prisma while using Postgres apart from the option of giving full admin rights?
Database user needs to have a CREATEDB privilege for using migrate commands in PostgreSQL.
Here's a reference to privileges needed for each supported database: Reference.
I have a PostgreSQL server on OVH's Cloud DB and have been using its databases for my web apps.
So far so good.
I got a project where It's a requirement to have schemas. Strangely enough, I am unable to create schemas on the user with "Administrator" privileges.
I have prepared scripts using schemas, so I just need to run them on a prepared database but I need a database with schemas to run them.
Here is my process:
Create a new database
Select option "Create user"
Select option for privilages: "Administrator"
Commit configuration
Wait for database creation
Connect to database with the new config via PGAdmin
Run command create schema if not exists "vMobile";
Recieve following error:
ERROR: permission denied for database my-database-dev
SQL state: 42501
I created a ticket for this but the wait is taking too long.
Support answer
Ok, so I got a response from the OVH support and there is no option for the user to create new schemas as their CloudDB enables access only to schema public and mentioned privileges Administrator, Read/Write, Read, None are only applicable to the public schema.
Workaround
My solution to this is to create tables with schema name included in their names
like so:
Desired outcome: "vCommon"."Route"
Workaround: "public"."vCommon_Route"
I have a funny question about PostgreSQL database: What happens if the postgres database is dropped?
dropdb postgres worked.
createdb postgres worked too.
psql worked.
But I thought the users would be lost. Yet the old users are still there.
So where are the users stored for the database and which implications does dropping the postgres database have?
PostgreSQL metadata are stored in catalog tables, which are in the pg_catalog schema. These are accessible like regular views and tables.
There are shared system catalog tables which are shared between all databases. These tables are not affected when databases are dropped.
pg_authid, the table where the users are stored, is one of those shared catalogs. This is because in PostgreSQL, users don't belong to a database, but to the whole database cluster.
You can list all shared catalog tables like this:
SELECT relname FROM pg_class
WHERE relisshared AND relkind = 'r';
In the documentation you can find more information about the system catalogs.
When connecting to a Postgres server, you always need to specify which database you want to connect to.
When you set up a new server, you need something to connect to before you can run your first CREATE DATABASE statement.
That's all the postgres database is: a dummy database to use as a connection target for admin commands. There's no data in there, and you're free to drop it and use a different one instead (though whoever inherits your system will probably not thank you for it...).
As gil.fernandes said in his answer, server-wide objects like users are accessible from every database, but aren't stored inside any database in particular.
Can I change PostgreSQL database schema in WSO2 IS? For default, it is public, but I want to change it to my custom one.
Please, help.
EXPLANATION:
I connected PostgreSQL database as primary database into WSO2 IS. First run wso2server.bat with -Dsetup parameter and all database tables was created in public schema of connected database.
I hope, that I can change default public schema to my own, for example wso2.
Yes it's possible. You have to modify the db scripts to use the custom schema with following line at the scripts.
SET search_path TO wso2;
Then set the search_path to include the schema you are using.
Refer the post here for more detailed steps.