• Hello Fabrik Community

    Fabrik is now in the hands of the development team that brought you Fabrik for Joomla 4. We have recently transitioned the Fabrik site over to a new server and are busy trying to clean it up. We have upgraded the site to Joomla 4 and are running the latest version of Fabrik 4. We have also upgraded the Xenforo forum software to the latest version. Many of the widgets you might have been used to on the forum are no longer operational, many abandoned by the developers. We hope to bring back some of the important ones as we have time.

    Exciting times to be sure.

    The Fabrik 4.0 Official release is now available. In addition, the Fabrik codebase is now available in a public repository. See the notices about these in the announcements section

    We wish to shout out a very big Thank You to all of you who have made donations. They have really helped. But we can always use more...wink..wink..

    Also a big Thank You to those of you who have been assisting others in the forum. This takes a very big burden off of us as we work on bugs, the website and the future of Fabrik.

Is there limit on amount of rows in lists in Fabrik?

fanta00

Member
When a list come close to about 400 records, it stops displaying in front end and page after loading for about 30sec finally throws 500 Internal Server Error. If I reduce number of records to about 300 it works (although is still slow). It doesn't matter how many rows I set to display at once. And I have about 30 elements in that table, displaying in the list view only 10 of them.
Is there a limit on amount of rows per table? I did some research and users only complained when they had more than 50 elements per table, it is said that number of records doesn't matter, however it does in my case. Is there anything I can improve to fix those issues? I do not want to split that table into smaller tables.
 
Your listing will be slow if a lot database join/cascading dropdown/repeat group/join with another table.

Example is :

List A have 100 element but only using field element on this table.

List B have 30 field but have a lot database join/cascading dropdown/repeat group/join with another table.

So remark is List A more faster than List B.
 
Hi fanta00,

Did you get the fix for this as in my case I cannot add more than 3000 records/rows in a csv file.

Thanks

Kashif
 
I've got lists sitting on tables with tens of millions of rows.

CDD's are really only ever a problem if your FK is using non-unique data, so you wind up getting in to geometrically increasing returned data set size, and that's an implementation problem (your data isn't normalized), not a Fabrik issue.

"Big selects" is typically only needed if you have a LOT of joins. And actually I think we now automatically set that, although I may be wrong.

-- hugh
 
I've got lists sitting on tables with tens of millions of rows.

CDD's are really only ever a problem if your FK is using non-unique data, so you wind up getting in to geometrically increasing returned data set size, and that's an implementation problem (your data isn't normalized), not a Fabrik issue.

"Big selects" is typically only needed if you have a LOT of joins. And actually I think we now automatically set that, although I may be wrong.

-- hugh
I only responded because I had the same problem - and it wasn't because of too many rows or repeat groups - its was because of a complex database join element query. Unless I enable big selects I will I have the exact same issue as described by fanta00. The lists created by database join elements would get truncated. (This is how I first learned about that 'Big Selects' setting to begin with.) I knew it was a bytes limitation issue because the truncation would occur in the middle of an element label/name. For example the labels in a database join selection for States would end with 'West Vir' (and any states after West Virginia didn't even show). There's a post somewhere in this forum from me dating back to when I first had that problem - and someone enlightened me on how to fix it.
 
I just had a look and it seems I dreamed setting big selects by default. Or rather ... I set it on the our default internal metadata session (the one we use for reading all the #__fabrik_foo tables), but not on sessions that we fire up for list data.

Next time I'm in that code, I'm just going to remove it as an option, and just set it on every session. Apart form anything else, our 'enable big selects' option also sets the group_concat length to 10k, without which results from WS_CONCAT() get truncated to some really short default length (252 I think). Which I think was probably what was truncating your "West Vir", as it was probably being generated with a WS_CONCAT() of a repeat join label.

-- hugh
 
Personally, I am continuously amazed at the knowledge that comes out of the fabrik support team. You have more knowledge of 'the big picture' than I have in my thumbnail. So having brain farts every now and then - not recalling if you did or didn't do something at some point in time - is more than understandable as far as I'm concerned. You have a lot on your plate. I just try to help when I can - and if that help refreshes your memory, that's yet another plus.:)
 
Thanks. I know we've had our differences in the past (and will no doubt have a few in the future), but I do appreciate all the work you put in, and your willingness to help others. Also very glad to see you starting to use github. It can be a steep learning curve, but it does make it sooooo much easier for us to integrate any bug fixes etc. you come up with.

-- hugh
 
We are in need of some funding.
More details.

Thank you.

Members online

Back
Top