if you use migrations, create new one and change the column via new migration
...
Schema::table('signs', function (Blueprint $table) {
//use your current column type instead of unsignedBigInteger, if needed
$table->unsignedBigInteger('po_id')->nullable()->change();
});
...
if not, update the column manually in a database client of your choice
@jlrdw How do you attach the image here loll sorry i am new here.
But i have to follow this due to weird client requirement.
lets say my signs table has two foreign ids project_id & po_id.
Think signs as a products. projects can have many signs/products. Instead of i suggest to have coupons client wants to add another sign which will have negative value and that will act as a coupon. so this wont have any po_id relation. Its weird. Our company also did not recommend this solution but they said thats how they are maintaining their sheet till date. and they want to follow this way.
/**
* Run the migrations.
*
* @return void
*/
public function up()
{
Schema::table('signs', function (Blueprint $table) {
$table->unsignedBigInteger('po_id')->nullable()->change();
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::table('signs', function (Blueprint $table) {
$table->unsignedBigInteger('po_id')->nullable(false)->change();
});
}