Library cannot handle ID columns with names other than the default

[csotiriou]

It looks like although the code for composite keys is there in the src/index.js file, the initialisation of the adapter doesn't take into account the 'idColumn' property of the Objection model.

This has led me to failed queries all the time which seem inexplicable if one does not enable the 'debug' mode of the knex module to see the actual queries made.

Steps to reproduce the faulty behaviour:

1. Go into any Objection model.
2. Set the idColumn property of the model to something that does not exist
3. Reboot your server. Make a GET /myModel/:modelID request. It shouldn't work, but it works. This means that the idColumn properly is not taken into account.

I have created a small patch to remedy this issue. @mcchrish Can you please check and merge?
#40

I believe that if this is OK, it justifies releasing 3.0.2 asap, as it is impossible to work with tables that has ID columns with name other than the name 'id;

[mcchrish]

Thanks for opening a PR 👍

pinging @dekelev

[dekelev]

@csotiriou Did you try to set the id property in the service options? https://github.com/mcchrish/feathers-objection#service-options

[csotiriou]

I apologize. Seems I totally missed that part of the documentation. Sorry for that, and thank you for your answer, @dekelev

On a sidenote, however, is there any reason why this property is part of the service configuration and not the model? Seems more appropriate to be part of the model, since it is also part of how the Objection library works (and seems to me that it is also semantically more appropriate).

[dekelev]

It's kind of a standard in feathers DB adapters, but I think it's a valid feature request to also use the model's idColumn in case the service.id is undefined. I'll check that over the weekend.

[dekelev]

https://github.com/feathersjs-ecosystem/feathers-objection/releases/tag/v3.1.2