Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modified backend and frontend for handling grouping of datasets #460

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

Hardiksh16
Copy link

No description provided.

@Hardiksh16 Hardiksh16 linked an issue Nov 12, 2024 that may be closed by this pull request
Copy link
Member

@MichaelRoeder MichaelRoeder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Writing "Ungrouped" or "Others" everywhere is not a good way to handle such a problem. Since the group is optional, the classes should offer a constructor without this attribute. The default value (e.g., "Others") should be provided in a static final class attribute.

There are also some other smaller changes needed. Please have a look at the single comments.

src/main/properties/datasets.properties Outdated Show resolved Hide resolved
src/main/properties/datasets.properties Outdated Show resolved Hide resolved
@@ -76,7 +76,7 @@ public static class ErrorCausingAnnotatorConfig extends AbstractAdapterConfigura
private int errorsPerHundred;

public ErrorCausingAnnotatorConfig(int errorsPerHundred) {
super("Error causing topic system", false, ExperimentType.ERec);
super("Error causing topic system","Un Grouped", false, ExperimentType.ERec);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use the static attribute that you defined further above.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't look like that 😉

@Hardiksh16
Copy link
Author

I have read your comments on the code and would refactor them as per your comments @MichaelRoeder

@Hardiksh16 Hardiksh16 marked this pull request as ready for review November 13, 2024 19:31
Copy link
Member

@MichaelRoeder MichaelRoeder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is just a small change request to make things nicer 🙂

@@ -306,18 +302,20 @@ public ModelAndView experiment(@RequestParam(value = "id") String id, HttpServle
}

@RequestMapping("/datasets")
public @ResponseBody List<String> datasets(@RequestParam(value = "experimentType") String experimentType) {
public @ResponseBody Map<String, List<String>> datasets(@RequestParam(value = "experimentType") String experimentType) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is a solution that would work 👍

However, the current implementation handles something that the Spring framework can already do for you. I am afraid that I have described the goal in an ambiguous way, so let me try to explain what I would suggest.
The method should return Map<String, List<DatasetCofiguration>> and the Spring framework should apply it's "magic" to transform it into JSON 🪄

Of course, Spring cannot do magic things, so we still have to provide the serialization 😉
However, it is sufficient if we tell Spring that there is exactly one class that implements the serialization and Spring can simply make use of it whenever it is necessary. You can do that with the method that is shown under point 3.2 in https://www.baeldung.com/spring-boot-customize-jackson-objectmapper (if I am not mistaken, I didn't read the whole text 😅 so let me know if you encounter problems). This method should go into our RootConfig.

serializedConfigs.add(json);
}
return serializedConfigs;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This serialization is actually not necessary. See comment further above.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove it, if it is not used anymore.

@@ -76,7 +76,7 @@ public static class ErrorCausingAnnotatorConfig extends AbstractAdapterConfigura
private int errorsPerHundred;

public ErrorCausingAnnotatorConfig(int errorsPerHundred) {
super("Error causing topic system", false, ExperimentType.ERec);
super("Error causing topic system","Un Grouped", false, ExperimentType.ERec);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't look like that 😉

Copy link
Member

@MichaelRoeder MichaelRoeder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The UI looks good but I think that we have a general misunderstanding how the workflow to achieve the targeted functionality should look like 😅
So let me bring up my points why I think the current solution is not exactly what it should be...

  1. MainController: I do not get, why the controller returns a Map<String, ...>. I assume that is done to make it easier for the UI to show the groups, because the data already comes in the form that the UI would like to have it. However, this is actually not really the task of the controller. If the UI would like to have the data in a certain form, it is free to organize the datasets by groups by itself. It is not really the task of the server to do that especially if we keep in mind that other (future) clients of the API are not interested in the group-wise order of datasets.
  2. MainController: the serialization is still explicitly done by ourselves while it should be done by the Spring framework. Yes, we can implement it by ourselves but what should we return in case of an error? At the moment, null is returned but that does not fit to the HTTP standard. So why shouldn't we let Spring do that for us, since it has already implemented all the error handling, etc...

I also added a comment that shows how I imagine it to look like.

<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
<version>2.7.15</version>
</dependency>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please move this dependency to the other Spring dependencies? Just search for the <!-- SPRING --> line to find them.

LOGGER.error("Error fetching datasets for ExperimentType: {}", experimentType, e);
return null;
}
return response;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This part should simply look like:

    public @ResponseBody Map<String, List<DatasetConfiguration>> datasets(@RequestParam(value = "experimentType") String experimentType) {
        ExperimentType type = null;
        Map<String, List<DatasetConfiguration>> response = new TreeMap<>();
        try {
            type = ExperimentType.valueOf(experimentType);
        } catch (IllegalArgumentException e) {
            LOGGER.warn("Got a request containing a wrong ExperimentType (\"{}\"). Ignoring it.", experimentType);
            return null;
        }
        return adapterManager.getDatasetDetailsForExperiment(type);
    }

Actually, the return null; is also not really nice... instead, we should return HTTP 400 with an error message.

serializedConfigs.add(json);
}
return serializedConfigs;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove it, if it is not used anymore.

import org.junit.Assert;
import org.junit.Test;

import it.unipi.di.acube.batframework.utils.AnnotationException;

public class ErrorCountingAnnotatorDecoratorTest {

private static String UNGROUPED = "Un Grouped";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why a different value than DatasetsConfig.DEFAULT_DATASET_GROUP is needed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Organize datasets in groups
2 participants