no, one-to-one relations aren't necessary unique. You can have a single object shared between multiple users.

In that case it's a one-to-many?

what do you mean? Case you provided is not valid for both one-to-many and one-to-one relations

For a one-to-one relation, you shouldn't be able to have multiple access tokens for one user. If that were the case, it would be a many-to-one relation on the access token and one-to-many on the user.

At the moment, it doesn't appear that there is any distinction between the columns created for these two types of relation. This is what the second spec is testing for.

yes, sorry looks like I was wrong. What is your suggestion? Add unique constraint on one-to-one relations?

Yes, I think it's a legitimated constraint to add 😄

I also think it could be done on top of this PR

We can try to add unique: relation.isOneToOne ? true : false here and check if it does the trick

I push the fix you proposed to see if the CI is happy with that.

@pleerock sorry for the delay, I've been busy.

Setting unicity on the column works only when the table is joined with one column. That's why I add a unique index when the table is joined with multiple columns. Here is the created indexes on table post defined on the spec functional/relations/multiple-primary-keys/multiple-primary-keys-one-to-one:

What do you think of this solution so far?

Some specs are missing, the same kind I added (checking trying to link the same object twice with a OneToOne relation) but on functional/relations/multiple-primary-keys/multiple-primary-keys-one-to-one.

Can you please create this PR against next branch? We are actively working on next version and planning to release this month plus this change is kinda serious so it will be better if it land in next. Also in next we are supporting UNQIUE CONSTRAINTS (not indices, except for mysql where INDEX and UNIQUE CONSTRAINT is the same) so you can use UniqueMetadata

The branch has been rebased and I used a UNIQUE CONSTRAINT instead of an INDEX. The CI doesn't pass but it looks like it's already broken on next branch. Don't hesitate to ping me back if there is anything I could do in order to see this PR live 😄

Lets merge it and see how it will work. Thank you very much for contribution!

@DFournier tests are failing currently on next and looks like because of this PR. Can you please take a look once?

Why do you have referencedColumns.length > 1 here? Shouldn't it be more the zero?

Because otherwise the constraint is set on the column itself here.

thats quite confusing logic and it should be set only in one place, otherwise it will be source of problems.

I agree, this comes from the very first implementation. I create a fix now :)