Fix default foreign key for PostgreSQL client

[ricardogama]

As shown on #8.

[petetnt]

Any pointers on where the bug is? This is blocking my usage of bookshelf-cascade-delete and I might as well take a stab on fixing it for good.

[ricardogama]

I'll try to take a look until the end of the week.

[ricardogama]

It looks that the default foreign key is being calculated correctly, from the Bookshelf docs:

ForeignKey in the Target model. By default, the foreignKey is assumed to be the singular form of this model's tableName, followed by _id

So following #8, the default foreign key would be Post_id but the actual foreign key of the Category table is post_id, and therefore the error is not related to quoting columns.

@petetnt Can you give a concrete example where this is failing? Otherwise I cannot reproduce the error.

[petetnt]

Actually I think my issue might be unrelated due to misunderstanding what default foreign key meant in this context (I assumed it as "the foreign key the field has in the DB", as I think my issues spawned from having a non-default (in Bookshelf.js sense) foreign key

For example something like

const addressModel = db.Model.extend({
 tableName: "address_table";
 ...
})
const fooModel = db.Model.extend({
  tableName: "foo_table",
  billing_address() {
   return this.belongsTo(addressModel, "billing_address");
 }
}, {
  dependents: ["billing_address"]
})

and the table structure would be something like:

knex.schema.table("address_table", (table) => {
  table.increments().primary();
  // other fields of an address
});

knex.schema.table("foo_table", (table) => {
  table.increments().primary();
  table.integer("billing_address");
  table.foreign("billing_address").references("address_table.id");
});

calling fooModel.forge({id: 1}).destroy() would result into delete from "address_table" where "id" IN ('123456') - column "id" does not exist.

Hopefully that made some sense, I wrote it out of my mind quite hastily. The example is a bit weird but it makes more sense with the actual names of the fields. That said, fooModel.forge({id: 1}).fetch({withRelated: ["billing_address"]}) works as it should:

fooModel.forge({id: 1}).fetch().then(address => {
  console.log(address);
  // results in:
  {
     "id": 1,
     "billing_address": 123456
  }
});

// with related:

fooModel.forge({id: 1}).fetch({withRelated: ["billing_address"]}).then(address => {
  console.log(address);
  // results in:
  {
    "id": 1,
    "billing_address": {
       "id": 123456,
       "other": "fields", 
       "of": "an", 
       "address": "!!!"
    }
  }
});

edit: Modified the example to be bit more concrete.

[ricardogama]

I believe the issue you're facing is the lack of support for belongsTo relations, which is fixed on #25 but it can't be merged until next Bookshelf release.

Anyway I'll try to create a fix for this by tomorrow and make a release, thanks for the report!

[petetnt]

@ricardogama neat 👍 I'll see and try running the queries against the PR (and Bookshelf master).

Thanks for the replies and keep up the great work!

[ricardogama]

I believe you have to use the tgriesser/bookshelf#1419 branch for that to work:

"devDependencies": {
    "bookshelf": "https://github.com/seegno-forks/bookshelf.git#bugfix/belongs-to-parent-id-attribute"
}

[ricardogama]

@petetnt It seems Bookshelf has new maintainers and has been active so I got some time to review some pending issues.

After some thought I realised that dependents of the belongs to relation should not be deleted in the first place, since it's a reverse relation and therefore the model that's being deleted is the one who has the foreign key.

Does this make sense in your case? If so can you confirm that #36 solves this issue?

Cheers!