-
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
Bug report: Total record/ pagenumber issue
- Thread starter koolaid2
- Start date
- Status
rob
Administrator
Ok I've tried fixing this in the SVN, if you wouldn't mind checking it out and letting me know if you spot any issues that would be great.
Hugh if you read this, when the 'merge join data' option is turned on, I've implemented what we discussed regarding building a list of the main table's ids and then filtering the main query's data on those ids rather than using limit x, y as we were doing before.
Hugh if you read this, when the 'merge join data' option is turned on, I've implemented what we discussed regarding building a list of the main table's ids and then filtering the main query's data on those ids rather than using limit x, y as we were doing before.
cheesegrits
Support Gopher
Rob, yup, I saw the commit. Been doing a lot of testing today to make sure those changes don't fubar anything else, so far it looks good.
BTW, I noticed a logic problem a few weeks ago with the way I originally implemented the merging. Basically, it ignores repeated data, i.e. data which is the same as the first row in the set of rows being merged.
This is a Bad Thing. For instance, if you have an element's set of joined data which was:
England
France
England
Germany
Italy
... after merging, it'll be ...
England
France
Germany
Italy
I don't know wtf I was thinking when I wrote that code. Anyway, we need to rethink the logic for how we actually merge the data down, probably by comparing the foreign key on the related data to the selected 'from element' param on the parent's join data.
My only excuse is I wrote that WiP merging coding back in 1.0.x days when I was MUCH less familiar with Fabrik than I am now!
-- hugh
BTW, I noticed a logic problem a few weeks ago with the way I originally implemented the merging. Basically, it ignores repeated data, i.e. data which is the same as the first row in the set of rows being merged.
This is a Bad Thing. For instance, if you have an element's set of joined data which was:
England
France
England
Germany
Italy
... after merging, it'll be ...
England
France
Germany
Italy
I don't know wtf I was thinking when I wrote that code. Anyway, we need to rethink the logic for how we actually merge the data down, probably by comparing the foreign key on the related data to the selected 'from element' param on the parent's join data.
My only excuse is I wrote that WiP merging coding back in 1.0.x days when I was MUCH less familiar with Fabrik than I am now!
-- hugh
cheesegrits
Support Gopher
Of course, what we should REALLY do is implement our concept of 'nested tables', probably generated via AJAX, which can be collapsed and inflated with some cute icon, but that's a 2.1 Thing.
However, the "WHERE id IN ()" change is a HUGE step forward to achieving better handling of joined row display.
-- hugh
However, the "WHERE id IN ()" change is a HUGE step forward to achieving better handling of joined row display.
-- hugh
- Status