Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Inconsistent use of set* and add*, especially in FileEntityBuilder

Ouverte
  • Quelque chose ne va pas ?
#242 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 12 jours

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
35/100
Type d'issue
Documentation
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
java
Domaine
documentation

Piste de recherche

Commencez par lire les méthodes de FileEntityBuilder mentionnées dans l’issue, puis comparez le comportement de add* et set* dans les autres builders d’entités. Documentez les objectifs et les différences observés, y compris les exemples pour setId, addProperty, addType, setLicense et setLocation ; l’issue ne nomme ni fichier de documentation ni test.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

invalid

As mentioned in #216 there is the need to document purpose and differences of add* and set* in general. While the actual purpose seems to be clear on the semantic level, it's almost impossible to estimate the effect of a set* or add* call without deeper knowledge of the code. Let's take the following example:

FileEntity file = new FileEntity.FileEntityBuilder()
                                .setId("survey-responses-2019.csv")
                                .addProperty("name", "Survey responses")
                                .addType("rdfs:Property")
                                .setLicense(new ContextualEntity.ContextualEntityBuilder().setId("licenseId").addProperty("name", "LicenseName").build())
                                .addProperty("contentSize", "26452")
                                .addProperty("encodingFormat", jsonNode)
                                .setLocation("http://example.com")
                                .build()
  • setId - Compared to other calls it should do the same as addProperty('@id', id), but holds id different than other properties, such that addProperty('@id', '123') would not work (and may even cause errors). Furthermore, if the id was already set, the call does nothing, such that overwriting an id is not foreseen (which is somehow fine).
  • addProperty - Should be better called setProperty(key, value), as previously added properties with the same name are overwritten. Thus, array values can only be set via addProperty(String, JsonNode). Therefore, one could think of either renaming addProperty to setProperty or changing its behaviour (see next point)
  • addType - Actually does what an add-method is supposed to do. At the first call it initializes a HashMap and adds the provided value, while subsequent calls add additional values to the HashMap. So basically the behaviour expected also for addProperty.
  • setLicense - One of the most confusing calls. In both cases, it internally calls addIdProperty("license", id). If you call it with a string argument, the value is assumed to be the license id and is directly used. If called with a ContextualEntity argument, getId() is used as license id, while the rest is omitted. Thus, the ContextualEntity of the license has to be added separately to the crate afterwards.
  • setLocation - Probably the most confusing call as there are more internal possibilities of what may happen. If called with an URI, the argument is set as id. If id was set before, the call is ignored. If called with a path and the id was not set before, the filename is used as id and path as location. If id was set before, path is only used as location without changing the id. If path is null, nothing is done (unless setLocationWithExceptions is used) and if path points to an non existing file, everything is fine until the crate is written and an exception is thrown.

For the moment, I just wanted to have these points documented for further discussions. I also have the impression, that for other entity builders the situation is much clearer (and mostly limited on the builder-level to set* for single values), but a consistent behaviour would be desirable.

Langage dominant
Java
Étoiles
5
Forks
4
Merge moyen
12 j 10 h
PR mergées (30 j)
8

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

  • Aucun Dockerfile ni fichier Docker Compose
  • Aucun modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de kit-data-manager/ro-crate-java

Toutes les issues de kit-data-manager/ro-crate-java

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.