[Bug] Unable to save select2_multiple when there are a large number of related objects

Bug report

What I did

I created a select2_multiple on a crud controller for “groups”. You can associate users to groups (in both directions)

What I expected to happen

The page would load and save when there are many users.

What happened

Once the number of users added to a group gets large, the page loads slowly and sometimes fails to save.

What I’ve already tried to fix it

Since this isn’t directly an issue with the code, nothing can fix it directly. The issue is the fact that there are too many users and every time we try to save the page we are trying to save every single user to the group and when the number of users in a group reaches large numbers, such as 3,000 it doesn’t really make sense to save every single user to the group every time you save a group. I don’t know if this is technically a bug because with only a few users it works.

Is it a bug in the latest version of Backpack?

After I run composer update backpack/crud the bug… is it still there? Yes

Backpack, Laravel, PHP, DB version

When I run php artisan backpack:version the output is:

PHP 7.4.18 (cli) (built: Apr 27 2021 14:35:46) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.18, Copyright (c), by Zend Technologies
    with Xdebug v2.9.8, Copyright (c) 2002-2020, by Derick Rethans

### LARAVEL VERSION:
v8.77.1@994dbac5c6da856c77c81a411cff5b7d31519ca8

### BACKPACK VERSION:
4.1.63@c3a09d64090cc15c51df7898889d763aaa335260

[zachweix]

Once I noticed this, I basically added in my crud controller that whenever a group has more than 200 users, to not add that column and instead add a “custom html” with text that says to go to an individual user to add/remove them from the group. I wonder if there should be a flag that you can set some custom number that when an n-n entity or 1-n entity reaches a certain number of elements that this type of text should replace the select field? If that’s so, then this is now a feature request, no longer a “bug” per se

[tabacitu]

Sounds like a reasonable solution. I don’t think a flag would be feasible, because… different people might prefer different solutions at different breakpoints. And while the breakpoint can easily be make customizable… the alternative solution… not so much. No matter how much we try to help in this case, the dev will still be forced to write some code to treat their particular case in their preferred way. So I say… let’s just do “nothing” 😀

Good question though.