-
Notifications
You must be signed in to change notification settings - Fork 11.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PostgreSQL dropPrimary does not work, if using prefix #42804
Comments
Actual code of migration file use Illuminate\Database\Migrations\Migration; return new class extends Migration {
};` |
Heya, thanks for reporting. We'll need more info and/or code to debug this further. Can you please create a repository with the command below, commit the code that reproduces the issue as separate commits on the main/master branch and share the repository here? Please make sure that you have the latest version of the Laravel installer in order to run this command. Please also make sure you have both Git & the GitHub CLI tool properly set up. laravel new bug-report --github="--public" Please do not amend and create a separate commit with your custom changes. After you've posted the repository, we'll try to reproduce the issue. Thanks! |
I'll re-open this once you provided a repo. |
@driesvints I am experiencing a similar issue, whereby I am struggling to remove a primary key that has a custom constraint name. This happened because I am moving an existing database over to using Laravel, so its tables were not set up by Laravel itself. I have never submitted a bug report for Laravel before, but hopefully I followed your instructions correctly on setting up a demonstraton repo, which can be found here: https://github.com/programster/Laravel-bug-report-dropPrimary They key commit demonstrating the bug is here: I made sure to test it was still the case after setting up PostgreSQL running in a docker container and updating my .env file database settings to: DB_CONNECTION=pgsql
DB_HOST=192.168.0.x
DB_PORT=5432
DB_DATABASE=bug_report
DB_USERNAME=laravel
DB_PASSWORD=laravel |
@programster I think:
|
@driesvints the first query where I'm creating the table.... ...is not supposed to show how I would have built it in Laravel, but to simulate the problematic table structure I have inherited by trying to move a legacy database over to Laravel. I am showing an example of how I am trying to fix it by using I don't think I need to split the operations into two migrations to demonstrate the bug, as the db statement query executes immediately, and it is the one that I need to execute first. If it makes you happier to demonstrate the point though, I would be happy to do so.... When I provide the name of the constraint to dropPrimary... ...it should be using that name in the query it uses to try and drop the constraint, instead of using its own derived name from looking at the table name. |
👍 I have the same issue |
@driesvints can yoiu re-open this issue now that you have the example info you asked for. Let me know if something is still outstanding. |
I'm sorry, but I don't think you should be using raw queries in that situation. Right now I don't have intention of reopening this. |
Your missing the point. The raw query in that case was simply to set up the state that the database is already in! Not a demonstration of the user using raw queries. What is the developer supposed to do if they are converting an existing codebase over to using Laravel, and the database (from the legacy system) already has primary keys that have an index name that Laravel is not expecting? This is what the sample codebase is trying to simulate to demonstrate the problem. At the moment, the developer is forced to use raw queries to drop the primary key to then "fix" the database so that they can use Schema in future, when they would rather just use Schema in their migrations without having to resort to using raw. |
Hello, I discover the exact same issue on my database using Postgres 15 and Laravel 10. According to me, issue seems to come from this place framework/src/Illuminate/Database/Schema/Grammars/PostgresGrammar.php Lines 383 to 388 in e3350e8
framework/src/Illuminate/Database/Schema/Grammars/PostgresGrammar.php Lines 428 to 433 in 256f497
In case a key name was provided, it's not used and hardcooded with current table name suffixed with In my case, I had a table that I renamed. public function up()
{
Schema::rename('corporation_mining_observer_data', 'corporation_industry_mining_observer_data');
} With this simple migration, I moved the table from So now, if I try to drop the primary key using this code: public function up()
{
Schema::table('corporation_industry_mining_observer_data', function (Blueprint $table) {
$table->dropIndex('corporation_mining_observer_data_pkey');
$table->primary(['corporation_id', 'observer_id', 'recorded_corporation_id', 'character_id', 'type_id', 'last_updated'],
'obeserver_data_primary');
});
} Laravel will replaced the provided name And of course, it crash because the constraint |
Fixed on Laravel 11.x via #50019 |
Description:
I can not drop existing index in my database (PostgreSQL) with standard migration.
The problem persist, if using PostgreSQL and prefix is not empty string.
The problem is in file:
https://github.com/laravel/framework/blob/9.x/src/Illuminate/Database/Schema/Grammars/PostgresGrammar.php
Line: 355
It generates index name without prefix.
When primary key index name is generating, it leaves naming for PostgreSQL, even if passing optional parameter $index. Generated SQL is something like:
alter table "prefix_test" add primary key ("id")
and PostgreSQL creates index name: prefix_test_pkey
When executing $table->dropPrimary(), raw sql is:
alter table "prefix_test" drop constraint "test_pkey", it does not add prefix and so migration throws error that:
constraint "test_pkey" of relation "prefix_test" does not exist.
It should generate prefix_test_pkey
Optionally $table->primary() and $table->dropPrimary() allows to pass index name, but PostgresGrammar ignores it.
Steps To Reproduce:
file: XXXXXX_create_test_table.php
id(); $table->dropPrimary(); }); } /** * Reverse the migrations. * * @return void */ public function down() { } };The text was updated successfully, but these errors were encountered: