...
- Generated CSV file is getting stored in a temporary folder(java.io.tempdir) on the file system. The available volume of the temporary folder depends on what the Java Virtual Machine is configured. When this folder gets overflowed, the job stops and gets FAILED execution status, and the description shows the exact error. Now the system doesn't provide ways to control the volume of the temporary folder, however, we can easily add such an ability, when we need it;.
- Mod-data-export-worker persists job execution parameters in the underlying database (table BATCH_JOB_EXECUTION_PARAMS). Developers from other teams increased the size of the column to store request parameters (10000 symbols for now). We should be careful with passing a lot of request parameters from UI (export fields and other request paramsparameters);.
- Storing files on Amazon Cloud will take some costs. We will set up a cleaner that will purge deprecated files, so this will help us to keep the storage in a good condition. Now parameters for the frequency of cleaning and time to keep files are hardcoded. In case we need to control this and set parameters on application startup, we can easily add such an ability;.
- There are no performance tests done and documented yet. We can do and document such tests, at least just to know how much time will take the export a limited some fixed number of records. Now we can rely on applications that use Export Manager for their exports;
...
Questions to the story:
- Should a user be automatically directed to the Export Manager after pressing the 'Export' button?
- Should the list of package&title fields be configured in Settings? Or it always will be hardcoded?
It makes sense to add a time to the generated file name (to make it unique)
...