Update Table: technology (rename to stack_element)

[Neecolaa]

Dependency

• 207

• 206

Overview

We need to update the technology table model to become the new stack_element table. We are consolidating language, technology, and tool into one table.

Details

• The initial model issue is #39

• Discussion leading to this change is here: #202

Action Items

• [x] Update existing Django model
• [ ] Write a test for the new relationships this model will have with other models (e.g., creating a user and assigning them a set of permissions on a project) if any.
• [ ] Update API end point
• [ ] Update API unit tests
• [ ] Document the endpoint in Swagger
• [ ] release #205 from ice box

Changes Needed

Columns to Remove

• None

Columns to Add

• [x] (FK) stack_element_type_id - int (see the Event model in models.py for how to do this. Also see discussion below on naming this to type)

Additional Changes

• [x] Change model name from technology to stack_element

Resources

• See People Depot Resources wiki page for links
  • ERD
  • Table and Field Definitions
  • API Endpoint

Model relationships

All the code here are not guaranteed to be correct or have correct syntax. It's just an explanation with example "code".

It's probably going to look something like this type = models.ForeignKey(StackElementType, on_delete=models.CASCADE)

The type name is so that when there's a StackElement object like language_python = StackElement.objects.create("python"), we can do python_language.type = type_language, where type_language is an object of StackElementType with the name "language".

The point is that python_language.type is easier to use than python_language.stack_element_type_id. In Django, the convention is to drop the _id for relationships.

Testing ideas

The stack_element_type object would hold something like "language", "technology", or "tool". The stack_element object holds the name of something in one of those categories.

Create a python language stack element

• create a stack_element_type object of "language"
• create a stack_element object of "python" with the "language" type
• check the stack_element's str method
• check that the stack_element's type is "language"

  classDiagram
  direction LR
  python --> language : has type

[AzaniaBG]

I can start working on this (I moved #64 to the Ice Box). Availability: Sunday 7 - 11 AM Wednesday 6 - 7 AM Thursday 6 - 7 AM

[ExperimentsInHonesty]

@AzaniaBG It looks like this issue has its dependencies completed. Is it ready to go back to the prioritized backlog?

[AzaniaBG]

@ExperimentsInHonesty, yes, we can do that.

[AzaniaBG]

@ExperimentsInHonesty ~ I'm ready to work on this issue. It looks like I don't need to do anything on #124. We can discuss at today's meeting.

[AzaniaBG]

@Neecolaa is the table name stack_element or stack_elements (plural)? The ERD has it as the latter, "stack_elements." I created the model with the singular form. Also, the ERD shows stack_elements relation to project_technology_xref, but I think this is supposed to be renamed to "project_stack_element_xref"

[AzaniaBG]

Updates

• figured out issue with ERROR [web 3/9] RUN apt-get update && apt-get when trying to build project -> Fang provided info and I realized I didn't have the latest code
• See this comment (above) for questions

Availability for next week:

• Thursday 3/14 6 AM - 7 AM
• Saturday 3/17 6 AM - 7 AM

[fyliu]

Yes, the django models should use singular names. Yes, you're right about the xref table naming. But, we might be able to use the builtin django many-to-many relation that manages the xref table automatically. See comment in #205 for a quick description of it.

[AzaniaBG]

Updated the following:

• technology model
• technology test in conftest.py
• technology test in test_models.py
• registered model

[Neecolaa]

Thank you for catching those discrepancies! Like Fang said, the table/model names are singular. I've corrected the ERD.

Likewise, project_technology_xref should be project_stack_element_xref as you both said. I've updated the ERD and the spreadsheet to reflect this. I also removed project_language_xref from the spreadsheet since that table's also being replaced by project_stack_element_xref.

If you do catch any more discrepancies please let me know!

[AzaniaBG]

updated the following:

• StackElement serializers
• ViewSet and register
• API test Note: unable to push the feature branch right now.

[AzaniaBG]

@fyliu ~ I tried your suggestion to change the FK "stack_element_type" to "type" and am getting the following errors:

I posted additional details in Slack. Can we work on this at tonight's meeting?

[fyliu]

Oh that's right, because type is a python keyword.

There's 2 issues:

The class member type needs to either change or worked around. I did something like this before so there might be an example in the code.

The database field name should remain the same. There's a way in the model field to specify the database field.

[fyliu]

Here's an example of using db_column to specify the database column name that's different from the field name.

For the linter messages. I have some old code that's not checked in that works around it. I'm not sure if it'll make it more difficult to use. I'm not able to find the source of that workaround.

class UserStatusType(AbstractBaseModel):
    """User status type"""

    class Status(models.TextChoices):
        INACTIVE = ("IN", _("Inactive"))
        ACTIVE = ("AC", _("Active"))
        TIME_AWAY_HOLD = ("AW", _("Time Away Hold"))
        BARRED = ("BA", _("Barred"))

    _type = models.CharField(
        max_length=2, choices=Status.choices, default=Status.ACTIVE
    )

    def __str__(self):
        return f"{self._type.label}"

And in Serializers.py

class UserStatusTypeSerializer(serializers.ModelSerializer):
    """Used to retrieve UserStatusType data"""

    _type = serializers.ChoiceField(choices=UserStatusType.Status.choices)

    class Meta:
        model = UserStatusType
        fields = (
            "uuid",
            "_type",
        )
        read_only_fields = (
            "uuid",
            "created_at",
            "updated_at",
        )

UserStatusTypeSerializer._declared_fields["type"] = serializers.CharField(
    source="_type"
)

[cnk]

I agree that _type is kind of ugly. How about calling it element_type?

[fyliu]

So the element could be things like aws, django, python, lucidchart, and we refer to the type as aws.element_type, django.element_type, python.element_type, and lucidchart.element_type. That makes sense and is better than the full name. Thanks for your help!

@AzaniaBG I think it's better to name it element_type and forget about specifying db_column.