Composite primary key

[haroldo-ok]

A quick question: are composite primary keys supported? Is it possible to make relations using those?

I'm asking this because we need to connect to a Firebird database that uses plenty of composite keys, and it has to be able to run alongside the existing lagacy system, so database refactorings won't be viable.

Also, is FB dialect 1 supported, or is it dialect 1, only?

[fijiwebdesign]

@haroldo-ok I don't believe there is composite key support. I'm using this for MySQL and haven't been able to use composite keys.

Also, I would suggest using another ORM as this project is no longer maintained for quite a while now. The last commit is: May 4, 2018

It has been the source of pain for one of the projects I'm working on that is using it (for over a year). At some point we will need to do a refactor to remove caminte.

[haroldo-ok]

Many thanks; I had also guessed as much; the only remaining options for Firebird ended up being:

• Using Objection.js plus an unnoficial driver: https://github.com/igorklopov/firebird-knex/issues/4
• Using an unnoficial fork of TypeORM: https://github.com/haroldo-ok/typeorm-firebird

In both cases, it was necessary to fix bugs on the unnoficial implementations, in order to make them work, but work, they did. I guess that's business as usual for legacy support...

[fijiwebdesign]

Keeping an unofficial driver updated seems much less risky than an unofficial fork.

If you're going to invest heavily in the ORM then most likely you won't be able to foresee the implementation details and bugs. I've come to the conclusion that for large projects it's better to avoid an ORM and build on knowledge you see in the drivers as examples. Build your own "ORM" as you go along.

The general sense I get is that:

• Most CRUD operations are simple db calls.
• The complex calls usually are related to the relationships being complex and thus can be too complex or inefficient when using the ORM.
• The "magic features" such as validation, security, watching changes (update events), etc. can be handled separately don't cost more to implement in the long run - there are many libraries available to base on.

A few things that costs dev time with caminte ORM was:

• It's inefficient when following relationships as each relationship is a separate db call. eg: Model.belongsTo(OtherModel...) would do a select call. I you have a Collection this is not feasible for the whole list. Worse when the dependency has an intermediate table in Model.hasMany()
• The API was inconsistent. eg: It would error when no results for findOne() with a null error then didn't error for find(). This is a pain over time when you debug older code.
• Implementation was incomplete and patchy.
• It was buggy and since inactive fixing bugs was not easy and cost more time than building the app.

Look out for these in the ORM you choose.