What's the preferred thing: multi-tabular or GenericRelation?



  • I'm doing a catalogue (internet store) on Django (for certain reasons it is necessary to write its own code rather than to use the solutions available).

    The question arises as to the structure of the OBD for the SEO fields (title, description, h1, url). Url should be unique (may contain / - so even Slug Field won't fit), all urls of level 1 (site.ru/my-category, site.ru/my-product, etc. - but part will be with "/" for compatibility)

    From the point of view of the PLO, it seems more logical to use inheritance:

    class SeoFields(models.Model):
        ...
        url = models.CharField(blank=True, null=False, max_length=200, unique=True)
    

    class Category(SeoFields):
    ...

    class Product(SeoFields):
    ...

    However, all management (especially the Two Scoops of Django) advise against the tabular inheritance.

    The Seo Fields model Fields is abstract, but then we're not automatically tested for uniqueness, and we're gonna find out what to show (temperature/category, etc.) will be more difficult (some requests for OBD).

    We can do without inheritance - add GenericForeignKey to Seo Fields. But then it will complicate the extraction of url for a specific object (+1 database request).

    Question: What type of OBD in this case is preferred? Is it worth avoiding the tabular inheritance, or is it appropriate here?



  • In this case, I would check the url field for uniqueness in the method save using the package. https://github.com/un33k/django-uuslug/ Somehow:

    class SeoFields(models.Model):
        url = models.SlugField(blank=True)
    
    def save(self, *args, **kwargs):
        if not self.id:
            self.slug = uuslug(self.name, instance=self)
        super(SeoFields, self).save(*args, **kwargs)
    

    It's not clear what the problem is: https://docs.djangoproject.com/en/1.9/topics/db/models/#multi-table-inheritance Actually, there's no need to complicate where the task can be handled by simpler methods. GenericForeignKey is not needed here.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2