Added CSV and Tableau export functionality

[markncooper]

** What is this PR for?

Allow users to export data in a paragraph to a CSV and / or Tableau via Tableau's WDC feature

** What type of PR is it?

Feature

** TODOs

This feature is partially incomplete - I want to drop the limit on only exporting 1000 (or however many) rows are shown in the UI. For our purpose we hacked backend support for this to our custom interpreter but I am looking for recommendations on the "proper" way to do this.

** Is there a relevant Jira issue?

Sort of - ZEPPELIN-672 is the most similar

**How should this be tested?

create a paragraph with data in %table view
select the "Export to CSV" or "Export to Tableau WDC" item in the paragraph settings list

** Does the licenses files need update?
NO

** Is there breaking changes for older versions?
NO

** Does this needs documentation?
Possibly. Here's a screenshot of it in action.

[zhongneu]

@markncooper I am working on a pull request for this: #714

I think we can directly export the data in frontend

[markncooper]

The big issue with simply exporting from the frontend is that you can only export as many rows as are displayed by the UI, right? I'd like to dump 1000s of rows.

[zhongneu]

@markncooper Right, but if the export button is in the chart interface, shouldn't we only export the rows shown in UI?

I also have a very similar case of exporting the "full report" than only the data UI shows. I am trying to work on some walk-around: create a dynamic form (or angular) for exporting the full reports, and register the exporting action on the dynamic form.

[jongyoul]

@markncooper@zhongneu Hello folks, this issue is handled by #6 initially. I think it's better that we focus one PR only. Do you mind improving #6 by comment or some implementations? In case of same issue with many PR, I think we should respect the first one. How about you guys?

[Leemoonsoo]

@markncooper Thanks for the contribution.

If you're trying to drop limit of number of rows to be downloaded, how about following approach?

Make an abstraction of any result data and share it to the ResourcePool. And then it can be used in rest end point to be downloaded. This approach was discussed in #413

[jmrr]

I'm a bit confused. @corneadoug said in #761 that this PR, #725, will handle the export via a REST call through the Settings button. However @jongyoul mentions that #6 will take care of this capability but @zhongneu is working on #714. At the same time #761 has been merged with a misleading title and reduction of features. I understand we haven't come up with the best approach but the issue would benefit from some consensus, as the approach of having multiple overlapping PRs on the same topic has hampered the development of the feature. I haven't started any of these PRs but I offer myself to test them and benchmark them.

[corneadoug]

@jmrr Yes, The goal was to take care of the export using #714 and #725 (for front and back-end export).
This would allow most of the PR to be merged, and a good thing about it is that the feature is not connected directly to the table plugin we want to use. #858 for example is proposing a new table.
#761 was merged without a change in title indeed (so it can be misleading).

[jmrr]

So how are we on this?

[corneadoug]

@jmrr Good Question.
Front-end Download has been merged, now we could also add some backend one for full data download.

@markncooper any feedbacks regarding @Leemoonsoo comments above?

[jmrr]

@corneadoug Edit my previous comment, the featured emerged when I disabled caching, the browser was caching the old view and it wouldn't appear. Sorry!

@corneadoug has front-end download really been merged? Do you mean #761 that was originally named "add download..." or something like that? Sorry but I don't see the download button :|

[sejunra]

any update on this?

[jongyoul]

It looks unmanaged now

[markncooper]

Yeah, I'll abort this change as it's been implemented by others.