-
New Commercial Services Section
We have now opened a commercial services section here on the forum for registered users. If you have a Fabrik project that you wish to have someone work on for you, post it under Help Wanted. If you are an application developer and wish to earn some money helping others, post your details under Fabrik Application Developers.
Both of these are unmoderated. It will be up to both parties to work out the details and come to an agreement.
-
Joomla 5.1
For running J!5.1 you must https://fabrikar.com/forums/index.php?wiki/update-from-github/ or include the new file manually https://fabrikar.com/forums/index.php?threads/joomla-5-1-and-fabrik-cannot-find-files-error.54473/post-285151 See also Announcements
Issue to see list After upgrade to Joomla! 3.8.3
- Thread starter confis
- Start date
cheesegrits
Support Gopher
I haven't noticed any issues being reported about 3.8.3, and can't replicate any problems here.
Can you fill out http://fabrikar.com/you/my-sites with a backend login, and I'll take a look.
-- hugh
Can you fill out http://fabrikar.com/you/my-sites with a backend login, and I'll take a look.
-- hugh
confis
Member
cheesegrits
Support Gopher
Erm .... and which list is it? I'd rather not go through every single one ...
-- hugh
-- hugh
confis
Member
confis
Member
cheesegrits
Support Gopher
I had a look at the Reports list (which as of today is rendering, albeit very slowly) and the immediate problem I see is that you have 5 join elements, some to quite large tables, none of which use the 'id' as the value - they all use the (non unique) label as the value (like 'customer_name'). That's going to cause terrible problems, for both speed and functionality. You REALLY need to redesign that, and use the PK of the joined table (usually 'id') as the value. That's why we put "(recommended)" next to it in the selection.
This isn't a Fabrik thing, it's a database thing. WHen joining rows in a relational database, you do it from FK (foreign key) to PK (Primary Key). Here's why ...
SELECT * FROM parent LEFT JOIN child ON child.parent_id = parent.id
... joins just that one record ... the child table has an FK which is the single, unique, indexed PK id of the parent.
Whereas ...
SELECT * FROM parent LEFT JOIN child ON child.name = parent.name
... trying to join them on a 'name' ... if you have two "John Smith" in the child table ... there is no way of knowing which one should be joined. And that select will get both.
Then when you do half a dozen joins like that, and any of them wind up with duplicated selections because of non-unique keys, you exponentially increase the number of rows being selected. A simple display of 10 rows can wind up trying to sort through tens of thousands of selected rows to find the distinct ones.
It won't be trivial to change, as you'll have to manually alter you existing table data to change it from label values to FK values. But this problem is just going to get worse and worse as your tables grow.
-- hugh
This isn't a Fabrik thing, it's a database thing. WHen joining rows in a relational database, you do it from FK (foreign key) to PK (Primary Key). Here's why ...
SELECT * FROM parent LEFT JOIN child ON child.parent_id = parent.id
... joins just that one record ... the child table has an FK which is the single, unique, indexed PK id of the parent.
Whereas ...
SELECT * FROM parent LEFT JOIN child ON child.name = parent.name
... trying to join them on a 'name' ... if you have two "John Smith" in the child table ... there is no way of knowing which one should be joined. And that select will get both.
Then when you do half a dozen joins like that, and any of them wind up with duplicated selections because of non-unique keys, you exponentially increase the number of rows being selected. A simple display of 10 rows can wind up trying to sort through tens of thousands of selected rows to find the distinct ones.
It won't be trivial to change, as you'll have to manually alter you existing table data to change it from label values to FK values. But this problem is just going to get worse and worse as your tables grow.
-- hugh