Hi, Wenhao.

Firstly, I would like to sincerely apologize for the delayed response as we have been experiencing an unusually high number of tickets. I am sorry that it has taken longer than usual to respond to your concern and your patience is highly appreciated.

-

I am sorry to disappoint you, but with our foreign key relations feature,

it is not possible to have one-to-many relationships.

If multiple entries share the same row ID , 

only the first value would be pulled, and it would ignore the other values with the same row ID.

During the foreign key relation configuration in our plugin, in this column settings you first choose the foreign table ID,

then you choose the Display Value and the Store Value.

For the Display value you can choose any column of the foreign table;

but for the 

Store value –  i thas to be a unique ID auto-increment column from the foreign table, 

values from which will be used as the unique row identifier,

so each ID can only have one corresponding row.

This is also the reason why for Editing, we can only choose the single-value selectbox as the only possible editor input type for those columns, since the options are limited with respect to what the remote table contains as unique values.

I will double-check with our 2nd level Team to see if they know of any kind of a workaround that might allow one-to-many relations with our plugin.

As soon as they confirm, i will report back. Thank you.

Hi, Wenhao.

Our 2nd level Team confirmed that with our plugin's foreign key relation feature,

it is not currently possible to have one-to-many relationships with our plugin.

For example, in our Employees Table, we have each employee have their own unique ID,

if we take this one, Steven Thorpe.  In the "employees" table, his ID is 5.

Then later on, as from our Foreign Key example Documentation,

if we make a relation in table "orders" – a ‘summary’ table about the orders, which stores information about the orders (order date, shipped date, taxes and fees), with “links” to the other three tables through ID fields – employee_id, customer_id, shipper_id;

each employee has a unique ID that we pull from the Employees Table. ( one to one relationship)

But for filtering, we can use a multiselectbox or checkbox for filtering in the table "orders",

in this way we can select multiple employees for filtering in the "employees" column.

So, the employee "Steven Thorpe" is repeated here because he made multiple orders and is displayed like that in the Orders table

 as his "display column" from table Employees is "full name", but the actual value that is stored in the database is integer 5, his employee ID.

Perhaps you already know all of this/ the logic behind it, if that is the case, i apologise for the unnecessary details,

but i just wanted to try this out in an example myself and to check if there is any workaround;

The same logic is applied for the filtering -  our plugin will pull the unique ID value for each possible filtering value, and it can only be one-to-one relationship.

But what you wrote in regards to "a dropdown with unique value options" , as you see, that is possible for a filter, multiselectbox or checkbox - but each employee has to have a unique ID.

If you wish to see a one-to-many possibility as a foreign key relation, you can add a future development suggestion if you wish to see this in the future,

but i can't say if or when it might be possible.

Please feel free to search on our suggestions page, 

 to see if someone may be already suggested this feature. If you can't see it, feel free to add your suggestion there,  and as more people vote, the feature will move higher on the priority list.

You can certainly follow our changeLog page if you'd like ( it is also available in the plugin dashboard), where we state any changes/new features/bug fixes during updates;

and our newsletter, so you're informed about new features, bug fixes, freebies, etc.

Hi, Wenhao.

Yes, at the moment it is unfortunately not possible in any way, but i hope that our developers might add a solution for this use-case in one of the future updates.

We will do our best.

Thank you for this suggestion and feedback.

Please don't hesitate to open new tickets if anything else comes up.