Improve logs v3

[andrey-katz-systemorph]

Moves the entire try - catch into a separate generic method. Writes down the switch statement in the ExecuteAsync in a concise manner and adds necessary constructors that are used in ReportInputAndUpdateActivityAsync method. To the import classes added methods WithSession, WithOptions, WithSetReader, to use in case these values are not set by a contructor.

[amuolo]

the extension methods WithActivityLog require every time the ISessionVariable, IDataSource, and IDataSetImportVariable to be provided. This makes the API lengthy and repetitive.
I recommend to:

• take dataSource from the builder,
• move the session and the importVariable to static properties of the newly defined ImportBuilderWriter and ExportBuilderWriter classes. At the end of this notebook, these properties will be assigned to Session and DataSetReader, respectively.

[amuolo]

Why are File and Activity two separate classes/tables? Is there a reason to prefer this design better than the simpler approach of having only one class with both info? In the presentation of this feature you anyway merged the information.
(I am not asking about feasibility, technicalities of which implementation might be coded. I am referring to the chosen code design.)

[andrey-katz-systemorph]

Why are File and Activity two separate classes/tables? Is there a reason to prefer this design better than the simpler approach of having only one class with both info? In the presentation of this feature you anyway merged the information. (I am not asking about feasibility, technicalities of which implementation might be coded. I am referring to the chosen code design.)

@amuolo I would say, there is a reason. Those are two conceptually different object, and I would not merge them in the DB. First, activity might or might not come with a file. In fact, there can be 4 different objects that are imported: Files, Strings, Streams and DataSets. As you see, all of them populate 4 different tables, they have different properties that characterize them, therefore damping them all into one table would just be a mess, and this actually defines the hierarchy of the abstraction layers in the file. In the presentation I showed the merger of these tables because this is what the client wanted in this particular case, but this infrastructure is supposed to tackle a much wider range of activities, therefore the split into different tables.

[andrey-katz-systemorph]

the extension methods WithActivityLog require every time the ISessionVariable, IDataSource, and IDataSetImportVariable to be provided. This makes the API lengthy and repetitive. I recommend to:

• take dataSource from the builder,

@amuolo , this is not possible, because this property of the builder is private protected, and no suitable public method exists to fetch it out. This issue was discussed with the developers team, there are reasons why it is not public and they are very reluctant of opening it for public use.

[amuolo]

Why are File and Activity two separate classes/tables? Is there a reason to prefer this design better than the simpler approach of having only one class with both info? In the presentation of this feature you anyway merged the information. (I am not asking about feasibility, technicalities of which implementation might be coded. I am referring to the chosen code design.)

@amuolo I would say, there is a reason. Those are two conceptually different object, and I would not merge them in the DB. First, activity might or might not come with a file. In fact, there can be 4 different objects that are imported: Files, Strings, Streams and DataSets. As you see, all of them populate 4 different tables, they have different properties that characterize them, therefore damping them all into one table would just be a mess, and this actually defines the hierarchy of the abstraction layers in the file. In the presentation I showed the merger of these tables because this is what the client wanted in this particular case, but this infrastructure is supposed to tackle a much wider range of activities, therefore the split into different tables.

Ok I see. Then I agree with you, better to keep the classes separate.

[amuolo]

the extension methods WithActivityLog require every time the ISessionVariable, IDataSource, and IDataSetImportVariable to be provided. This makes the API lengthy and repetitive. I recommend to:

• take dataSource from the builder,

@amuolo , this is not possible, because this property of the builder is private protected, and no suitable public method exists to fetch it out. This issue was discussed with the developers team, there are reasons why it is not public and they are very reluctant of opening it for public use.

What we can do at this point is to use static properties and assign to them the global variables Session, DataSource and DataSetReader. In this way we can improve the API.

[andrey-katz-systemorph]

the extension methods WithActivityLog require every time the ISessionVariable, IDataSource, and IDataSetImportVariable to be provided. This makes the API lengthy and repetitive. I recommend to:

• take dataSource from the builder,
• move the session and the importVariable to static properties of the newly defined ImportBuilderWriter and ExportBuilderWriter classes. At the end of this notebook, these properties will be assigned to Session and DataSetReader, respectively.

I agree that this is a better solution, and in fact much better in the long term than we have right now. This would lead to a minor change in API, something that was discouraged at this point, but I think that we can still do it. @dcolleoni , do you agree we can still afford ourselves a minor API change here?

[dcolleoni]

@andrey-katz-systemorph pls create a new issue with the improvement previously suggested by Daniel and those arising from your discussion with @amuolo. Assign release 1.1.x to the new issue.
The issue #167 is meant for release 1.1.0 and it is completed with the scope required by that release.
Thanks.