Option to split data files after export

[maeg02]

Consider that you want to use your data file as a base for version control. However that would be easier to do if this tool would split the data file into entity folders and then into one file per record.

One could consider ids as filenames or use the definition import match attribute as a filename.

[rappen]

Interesting approach.

It might make distribution a bit more complex, as you would have to supply the whole file/folder structure, instead of just the data file and the definition file.
The order in which the files are read during import is also vital, to maintain dependencies etc, that would have to be handled in some way, maybe by keeping the one centralized data file but not have the actual data in it, but rather references to the individual data files.

From a version control aspect it absolutely makes sense.

[maeg02]

Correct, that would be hard.

I thought outside the scope of actual data "shuffle" and only be able to re-import the data back in version one, in case of data recovery is needed.

If I made a suggestion PR, is this even a good idea for this repo? Might there be a better way?

[imranakram]

Thanks for the input. Watch out for the features/utils branch where we're working on the next version.

[maeg02]

Thanks for the input. Watch out for the features/utils branch where we're working on the next version.

So that means I should not start a "PR discussion" with some psedo code?

[rappen]

@imranakram are there issues we could watch to track the work/progress/ambitions?

[imranakram]

@rappen Here's the issue #23. The idea is to replace the DevUtils nuget with the new Xrm.Utils project to make it fully open source. So I've made some updates to both projects lately.

@maeg02 It's a work in progress at the moment and I work from time to time on it but not regularly. Feel free to chip in as you like :)