Possible ListOperation optimizations

[tabacitu]

@mahasadhu said this in #3132 - moving here because it's off-topic:

---

@tabacitu - I see... so that how it should be used.

Currently I'm using setFromDb() because that's what I saw on docs. And then I modify any columns that I need using modifyColumn() or modifyField().

But then again, sometimes modifyColumn() or modifyField() does not work (not sure why), and I'm simply call removeField() then addField() right after it to make it works.

And today I just realized, that looks like setFromDb() executes query from information schema. And that query becomes the longest one to run / execute.

Looks like there are quite some things that I need to update from my code 🤕

---

By the way today I tried to run DB::getQueryLog() on the search method in Backpack. And it seems like there are some things that could be optimized. For example this one below, there is one exact same query without any parameters that executed twice.

It looks like being used to show total number of record / row in that particular table. It looks like the problem is around here
https://github.com/Laravel-Backpack/CRUD/blob/5414225a0040f2b8b18eb9e3a55d613bfb8d3db6/src/app/Http/Controllers/Operations/ListOperation.php#L76-L77
But still, I'm not sure whether this is my mistake, laravel / eloquent mistake, or actually a bug inside the Backpack.

This last bit could be in a different issue though.

Originally posted by @mahasadhu in Laravel-Backpack/CRUD#3132 (comment)

[tabacitu]

And today I just realized, that looks like setFromDb() executes query from information schema. And that query becomes the longest one to run / execute.

Yeah, that's just one of the reasons we've stopped recommending setFromDb(). The other being that it's IMPOSSIBLE for us to push changes to it, if people use it in production. Any change we make will make thousands of admin panels behave differently than what they did before the change. Not good.

Currently the recommended way to use Backpack is the one in the video course, which is also the one that our generators use - the new fluent syntax in Backpack 4.1. But I just realised - we do NOT teach/recommend the same fluent syntax in the text tutorials - so thank you, I've just made a note to fix this.

By the way today I tried to run DB::getQueryLog() on the search method in Backpack. And it seems like there are some things that could be optimized. For example this one below, there is one exact same query without any parameters that executed twice.

Indeed, there might be a few things we can optimize in terms of queries on the List operation. We're open to suggestions. The biggest optimization we can make, though, is getting rid of DataTables. It has served us VERY well for a number of years, but now it's holding us back - difficult/impossible to support billions of rows (because it still needs pagination numbers), difficult o make one row a certain color. In a future version we plan to code something from scratch for this operation, probably using Livewire. But until then - optimization are welcome and very appreciated.

I agree - we've diverged enough, let's keep this issue about the Show operation and open other Issues/Discussions for other stuff.

[tabacitu]

Update: moved your question and my reply in a different thread, in Discussions.

[mahasadhu]

Welp, that crud fluent syntax page just blown my head 🤯 Apparently I've been using backpack at the most non efficient way.
Feels bad not reading the documentation thoroughly.

You're welcome, I'll also try to push some PR in my spare time to the docs repository. Some other things that I've found lately is request is now protected, so we need to use getRequest() in controller to actually get the request. But it still mentioned in some places, for example:

I understand that it's really hard to make a good docs, however good docs is one of the major key selling points in libraries like Backpack. Better docs, better adoptability.

Ah, me and my team just started to use Livewire, but only for things like reporting. We are still not sure whether it's good enough to use Livewire extensively, because it's relatively new. But it looks quite promising imho.

[tabacitu]

Where's your first screenshot from? Can't find it 😄

Changed the second one, it was in the Create docs. Thanks!

Welp, that crud fluent syntax page just blown my head 🤯 Apparently I've been using backpack at the most non efficient way.
Feels bad not reading the documentation thoroughly.

Yeah the fluent syntax was added in 4.1 so we were reluctant in making it "the default". But now that it's mature, and most kinks are ironed out, I think we'll promote that one everywhere in the docs, starting with 4.2. We'll leave the addField() as a backup, of course. But it's much faster and shorter to use the fluent syntax.

Ah, me and my team just started to use Livewire, but only for things like reporting. We are still not sure whether it's good enough to use Livewire extensively, because it's relatively new. But it looks quite promising imho.

Same hear. Love it for some stuff, but I'm reluctant on depending too heavily on it. It's a pitty, because it would be PERFECT for rewriting the ListOperation to something that uses zero javascript. And also for rewriting the InlineCreate functionality and having dependant fields, things like that that you currently have to code in JS. I'd much rather code in PHP than JS. We'll see where the future takes us but right now I have high hopes for LiveWire 😄

[mahasadhu]

Ah thank you! The first one is here https://backpackforlaravel.com/docs/4.1/crud-cheat-sheet#custom-advanced-queries

[jcastroa87]

Hi.

Due to not activity on many years i will close this discussion, if there is needed feel free to reopen or create a new one.

Cheers.