Clarification on Relationship Generation in sea-orm-cli Based on ForeignKey Constraints

Hello sea-orm team,

I am encountering a situation where the sea-orm-cli generate entity command generates different relationship annotations based on how the foreign key constraints are specified in the SQLite schema. Specifically, there seems to be a difference in behavior when the UNIQUE keyword is used.

Here's a detailed example using two tables, Authors and Books, to illustrate my point:

Schema Definition

CREATE TABLE Authors (
    ID INTEGER PRIMARY KEY AUTOINCREMENT,
    name TEXT NOT NULL
);

CREATE TABLE Books (
    ID INTEGER PRIMARY KEY AUTOINCREMENT,
    authorID INTEGER,
    title TEXT NOT NULL,
    FOREIGN KEY (authorID) REFERENCES Authors(ID)
);

CREATE UNIQUE INDEX idx_books_author ON Books (authorID);

With this schema, I expect that the relationship generated should indicate a one-to-one relationship (has_one) between Authors and Books due to the unique index on Books.authorID. However, the behavior seems inconsistent depending on the placement and usage of UNIQUE constraints directly in the table definition versus the creation of a unique index separately.

Could you please clarify the following:

How does sea-orm-cli generate entity determine when to generate #[sea_orm(has_one = "related_entity")] vs #[sea_orm(has_many = "related_entity")]?
Is there a recommended way of defining foreign keys and unique constraints in the schema to ensure consistent relationship generation?
Any guidance or clarification on this matter would be greatly appreciated.

Thank you for your assistance!

##Versions
├── sea-orm v0.12.14
│ ├── sea-orm-macros v0.12.14 (proc-macro)
│ │ ├── sea-bae v0.2.0 (proc-macro)
│ ├── sea-query v0.30.7
│ │ ├── sea-query-derive v0.4.1 (proc-macro)
│ ├── sea-query-binder v0.5.0
│ │ ├── sea-query v0.30.7 ()
├── sea-query v0.30.7 ()
│ ├── sea-orm v0.12.14 ()
│ ├── sea-query v0.30.7 ()

Start at the sea-orm-cli generate entity entry point and reproduce the Authors/Books SQLite schema shown in the issue, comparing an inline UNIQUE constraint with the separate unique index. Trace how the foreign key metadata becomes has_one or has_many; done means the behavior is explained and any inconsistency is documented or corrected.