6.0.10 db read model relationship broken

grantdigital 17 Apr, 2019
HI
with the 6.0.10 update, the db read model relationship is broken. It now keeps defaulting to is the id on the primary table regardless of what I have set.

6.0.10 db read model relationship broken image 1

Here is the query output which should be `Date`.`cid_1` = `C2`.`id` not `Date`.`id` = `C2`.`id`
SELECT `Date`.`id` AS `Date.id`, `Date`.`cid_1` AS `Date.cid_1`, `C1`.`alias` AS `C1.alias`, `Date`.`cid_2` AS `Date.cid_2`, `C2`.`alias` AS `C2.alias`, `Date`.`cid_3` AS `Date.cid_3`, `C3`.`alias` AS `C3.alias` FROM `xmas_cracker` AS `Date` LEFT JOIN `pxqun_gb_xmas_catalog_clients` AS `C1` ON `Date`.`id` = `C1`.`id` LEFT JOIN `pxqun_gb_xmas_catalog_clients` AS `C2` ON `Date`.`id` = `C2`.`id` LEFT JOIN `pxqun_gb_xmas_catalog_clients` AS `C3` ON `Date`.`id` = `Date`.`cid_3` WHERE `Date`.`start_date` = '2019-04-17'
Max_admin 17 Apr, 2019
AS `C1` ON `Date`.`id` = `C1`.`id`
This is based on your foreign key, if you prefer a different rule then just clear the foreign key field!

Best regards
Max, ChronoForms developer
ChronoMyAdmin: Database administration within Joomla, no phpMyAdmin needed.
ChronoMails simplifies Joomla email: newsletters, logging, and custom templates.
grantdigital 17 Apr, 2019
It should be `Date`.`cid_1` not `Date`.`id` like it is and that where I have the problem, older versions correctly used the 'Relation Conditions' but now that is not having an effect.

The system is deciding on using id from the Date model and not the field I want. Normally not would want the primary key of 2 models to be the field that relates to each other.
healyhatman 17 Apr, 2019
Where is the foreign key, is it in C1 or is it in Date? Because it LOOKS like it should be "Foreign key in the other table" and you should set the foreign key field name to "cid_1"
grantdigital 17 Apr, 2019
Looking at another version of the same connection I was using on another site. I used
Well this what I get when I put cid_1 on the Foreign key'

An error has occurred.
1054 Unknown column 'C1.cid_1' in 'on clause'

I have tried nearly everything and I can not change the field that the relationship is using from the date field. The only thing I can seem to change is the par that `Date`.`id` is compared to and not the `Date`.`id` part.

The 'Relation Conditions' is meant to do this but now this field is not getting used in building the query.

This worked completely fine in older versions of Connectivity v6, it not working correctly in v6.0.10
healyhatman 17 Apr, 2019
The difference is that the way it's working now is actually fixed, whereas before it wasn't working consistently. Did you change the dropdown like I said to? To one matching record, foreign key in the other table?
Max_admin 18 Apr, 2019
1 Likes
Please CLEAR the foreign key field, a new code change was to use the foreign key if it exists, if not then it will use the relation conditions.

Let me know how that works!
Max, ChronoForms developer
ChronoMyAdmin: Database administration within Joomla, no phpMyAdmin needed.
ChronoMails simplifies Joomla email: newsletters, logging, and custom templates.
grantdigital 22 Apr, 2019
by changing relation is worked again. Also, I think the way the labels are could be confusing to people as they are more commonly called 1:many, many:1 or many:many.

Another thing better information on how the relations interact with the option would also be helpful.
healyhatman 22 Apr, 2019
I would think those labels would be a lot worse and a lot more confusing to the average user. Not everyone has DB experience and "many:1" is a lot less useful than "One matching record, foreign key at the related table".

That being said slightly more information would be useful, like the bit about manual conditions being overridden when you have a value in the Foreign key field.
grantdigital 23 Apr, 2019
Ok, I would think the term 'foreign key' would be confusing to normal people.

I not sure but could you add some JS to display how the join will be added to the query.
This topic is locked and no more replies can be posted.