[Feature Request] Export operation

[tabacitu]

Instead of using DataTable's magic to export rows, we should create an Export operation. That way:

• we could even customize how it's done, add different export formats, etc;
• it would fix the problem of having to see all entries that are exported (known limitation of the DataTables export when using AJAX);

The way I see it:

• the operation adds a single "Export" button to the bottom stack;
• click the button and it opens a modal; in that modal, you can
  • choose which columns to show in the export;
  • (maybe) reorder the columns in the export;
  • choose the export format (XLS, CSV, PDF);
  • choose to export:
    • All rows (124.141 entries)
    • Filtered rows (45.133 entries)
    • Currently visible rows (25 rows)
    • Currently selected rows (5 rows)
  • click "Download" and you get the file you want; the file itself is generated using PHP generators, so that you can export even millions of rows;

[ziming]

That's very nice! This is 1 of the things I worry about as my table gets bigger hehehe. Actually I already have this problem now

[ziming]

Sorry I only saw this after I make a new discussion.

Consider looking at https://github.com/yajra/laravel-datatables-export

[mamarmite]

I didn't know about the package @ziming shared.

I've made a version 0.0.2 of this. Really basic operation, still wip : https://github.com/mamarmite/export-operation
(I've shared with @tabacitu , but I think it was a bit before the v5 release, so this would have eclipsed. No problem.

When I upgrade the project to 5, I'll retouch that package.
(Note I put it in the backpack namespace, but I'm not part of the project. I'm just an enthusiast. I developed it that way, for if Tabacity added the repo.

[tabacitu]

Heads-up @mamarmite , @pxpm is also working on an official export operation, but he's hit a wall at high numbers (100.000 + records). Seems like that can't really be done without queueing... how many rows have you tried (max) with your solution?

It'd be interesting to compare the two solutions and see what we can do about this... I really want us to have a built-in server-side export solution, but it's imperative that it also covers lots and lots of records, otherwise... it's not a complete solution to the problem...

[mamarmite]

The operation I've started, relays only on the server resources. So it would hit the max script-time / ram / etc. So I would assume queuing for larger size is the only solution indeed.
No problem @tabacitu , I understand completely the direction you're taking. And I +1 for you plan!
I'll change the name space of my current basic export that uses only the servers-resources-would-allowed to keep it for my current project.

I would share/ask for something I'm not sure about :
If I implemented an app that would manage that much of the data.
I would try to use Redis or something alike at the app's DB driver scope. And Assume I can plug my App to it.
But that path would have a lot of "pandora's box", I called them (a feature I think is that big, and finally it really much bigger). Anyhow, I'm sure you would find a way <3

I've used some app that send a link via email to download the export when it's ready with this kind of flow. It's kinda cool UX may I say.

1. Click to export
2. Select the options available to you (cols, format, etc)
3. Click export
4. Explain that you will receive an email when it's ready
5. Email received click on the link that will contain the file

Thank you, for listening to the community. You're awesome.