feat: ✨ [NEW FEATURE]Create relation between Item and Event, Item and Place, Place and Event by create-issue-branch[bot] · Pull Request #499 · org-SCAN/website

create-issue-branch · 2024-07-16T12:35:34Z

Original issue description

Description of the desired solution
• Instead of manually adding which event a person was in, a relation must be created between the person and the event. Avoids having an item in multiple events.
• An item can have a localization, so a relation between place and item is necessary
• A event can have a localization, so a relation between place and event is necessary
closes #496

closes #498

[skip ci]

…ion was done for api_log in place

sonarqubecloud · 2024-08-07T19:49:47Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
68.8% Coverage on New Code
1.4% Duplication on New Code

See analysis details on SonarCloud

…relation_between_Item_and_Event_Item_and_Place_Place_and_Event

sonarqubecloud · 2024-10-08T05:56:41Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
68.8% Coverage on New Code
1.4% Duplication on New Code

See analysis details on SonarCloud

lduf

This should work, but I would prefer to use something more dynamic. There are many code similarities / repetition and adding a new type of relation won't be easy.
I explained what I was thinking to do to chatGPT and ask it to explain it in a more comprehensive way.

Here is what it said :

Explanation and Detailed Proposal

Objective:

The goal is to create a flexible and scalable system to manage relations between different models (e.g., Item, Place, Event) in a way that avoids code duplication and adheres to clean code principles.

Current Issues:

The current approach in the PR involves a lot of repetitive code to establish relationships between models. This can be improved using a more abstract and generalized approach.

Proposal:

Abstract Class/Interface:
- Create an abstract class or interface that defines the common behavior for all models that can have relations. This class will be called Relationable.
Inheritance:
- Each model that needs to have relations (e.g., Item, Place, Event) will inherit from the Relationable class.
Allowed Relations:
- Define a list of allowed relations in the parent class. This list will specify which models can be related to each other.
Dynamic Relation Methods:
- Use dynamic methods to handle the creation and management of these relations, reducing the need for repetitive code.

Example Implementation:

1. Creating the `Relationable` Abstract Class:

abstract class Relationable extends Model
{
    protected static $allowedRelations = [];

    public function addRelation($relationType, $relatedModel)
    {
        if (!in_array(get_class($relatedModel), static::$allowedRelations)) {
            throw new Exception("Relation not allowed");
        }

        // Logic to add the relation
        // This is a simplified example, and you would expand on it as needed for your project.
        return Link::create([
            'from_id' => $this->id,
            'from_type' => get_class($this),
            'to_id' => $relatedModel->id,
            'to_type' => get_class($relatedModel),
            'relation_type' => $relationType,
        ]);
    }

    public function getRelations($relationType)
    {
        // Logic to get the relations
    }
}

2. Extending Models from `Relationable`:

class Item extends Relationable
{
    protected static $allowedRelations = [Place::class, Event::class, Item::class];
}

class Place extends Relationable
{
    protected static $allowedRelations = [Event::class];
}

class Event extends Relationable
{
    protected static $allowedRelations = [Event::class];
}

3. Using the New Structure:

$item = Item::find(1);
$place = Place::find(2);
$event = Event::find(3);

$item->addRelation('location', $place); // Allowed
$item->addRelation('participation', $event); // Allowed

$place->addRelation('host', $event); // Allowed

$event->addRelation('related', $event); // Allowed

$place->addRelation('residence', $item); // Throws exception (not allowed)

Detailed Example:

Defining a Relation:
- In the Item model, we can define that it can have relations with other Items, Places, and Events.
- In the Place model, we define that it can have relations with Events only.
- In the Event model, we define that it can have relations with other Events.
Handling Relations:
- The addRelation method in the Relationable class checks if the relation is allowed before creating it.
- This ensures that you cannot create invalid relations, maintaining the integrity of your data.

Benefits:

Reduced Code Duplication: By centralizing the relation logic in the Relationable class, you avoid repetitive code across different models.
Flexibility: You can easily add or remove allowed relations by modifying the $allowedRelations array in each model.
Scalability: This approach is scalable and can easily accommodate new models and relations in the future.

This structure ensures a clean, maintainable, and scalable way to manage relations between different models in your project.

PS : you might need to refactor many models and migration.
I think you should add from_type and to_type columns to support polymorphic relationships to links table. This allows any model to be related to any other model.

lduf · 2024-10-08T10:58:01Z

+        return $this->hasOne(ApiLog::class, 'id', 'apiLog_id');
+    }
+
+    public static function getAllPlacesNames() {


Use pluck instead :

public static function getAllPlacesNames() { return self::pluck('name', 'id'); }

lduf · 2024-10-08T11:00:45Z