EAV-Django

EAV-Django er en genbrugelig Django app, der giver en implementering af enhedsniveau Attribut-Value datamodel.
& Nbsp; Entity-Attribut-Value-modellen (EAV), også kendt som objekt-attribut-værdi model og åbne skema, som bruges i tilfælde, hvor antallet af attributter (egenskaber, parametre), der kan bruges til at beskrive en ting (en " enhed "eller" objekt ") er potentielt meget stort, men antallet, der rent faktisk vil gælde for en given enhed er relativt beskeden.
EAV-Django virker fint med traditionel RDBMS (testet på SQLite og MySQL).
Prioriteter
Ansøgningen voksede fra en online shop projekt, så det er temmelig praktisk og ikke bare en akademisk øvelse. De vigtigste prioriterede områder var:
& Nbsp; 1. fleksibilitet af data,
& Nbsp; 2. effektivitet af forespørgsler, og
& Nbsp; 3. maksimal vedligeholdelse uden at redigere koden.
Selvfølgelig indebærer dette afvejninger, og målet var at finde den mindst skadelige kombination til det generelle tilfælde.
Egenskaber
Alle forudsat modeller er abstrakte, dvs. EAV-Django gemmer ikke nogen oplysninger i sine egne tabeller. I stedet danner grundlag for dine egne modeller, som vil have støtte til europæisk merværdi ud af kassen.
Den europæiske merværdi API indeholder:
& Nbsp; * Opret / opdater / adgang: model forekomster giver standart API for både "rigtige" marker og EAV attributter. Den abstraktion, dog ikke stå i vejen og giver midler til at håndtere den underliggende ting.
& Nbsp; * Forespørgsel: BaseEntityManager omfatter ensartet tilgang i filter () og udelukke () for at forespørge "rigtige" og EAV attributter.
& Nbsp; * Tilpasses skemaer for attributter.
& Nbsp; * Admin: alle dynamiske egenskaber kan være repræsenteret og ændres i Django admin med ingen eller lille indsats (ved hjælp eav.admin.BaseEntityAdmin). Skemaer kan redigeres separat, som almindelige Django model objekter.
& Nbsp; * facetter: facet søgning er et vigtigt element i online-butikker, kataloger osv Grundlæggende skal du bruge en formular, der repræsenterer en bestemt delmængde af model attributter med passende widgets og valg, således at brugeren kan vælge ønskelige værdier af nogle egenskaber, indsende formularen og få en liste med matchende poster. Generelt tilfælde Django-filter ville gøre, men det vil ikke fungere med EAV, så EAV-Django indeholder et komplet sæt af værktøjer til det.
Eksempler
Lad os definere en EAV-venlig model, skabe en europæisk merværdi attribut og se, hvordan den opfører sig. Med "EAV attributter" mener jeg dem, gemt i databasen som separate objekter, men adgang til og søgte på en sådan måde, som om de var kolonner i virksomhedens tabel:
fra django.db import- modeller
fra eav.models import BaseEntity, BaseSchema, BaseAttribute
class Frugt (BaseEntity):
& Nbsp; title = models.CharField (MAX_LENGTH = 50)
class Schema (BaseSchema):
& Nbsp; pass
class Attr (BaseAttribute):
& Nbsp; skema = models.ForeignKey (Schema, related_name = 'attrs «)
# I Python shell:
# Define attribut med navnet "farve"
>>> Color = Schema.objects.create (
... Title = 'Colour',
... Name = "farve", # undlader at udfylde / slugify fra titel
... Datatype = Schema.TYPE_TEXT
...)
# Oprette en enhed
>>> E = Fruit.objects.create (title = "Apple", color = "green")
# Definere "rigtige" og EAV attributter på samme måde
>>> E.title
'Apple'
>>> E.colour
"Grønne"
>>> E.save () # omhandler EAV attributter automatisk
# List EAV attributter som attR-forekomster
>>> E.attrs.all ()
[]
# Søgning ved en EAV attribut, som om det var en almindelig felt
>>> Fruit.objects.filter (color = 'gule')
[]
# Alle sammensatte opslag understøttes
>>> Fruit.objects.filter (colour__contains = 'råbe')
[]
Bemærk, at vi kan få adgang til, ændre og forespørgslen farve, som om det var en sand felt enhed, men samtidig sit navn, type og endda er eksistens helt defineret af et Schema instans. Et skema objekt kan forstås som en klasse, og beslægtede attR-objekter er dens instanser. Med andre ord, skemaobjekter er ligesom CharField, IntegerField og sådan, kun defineret på data-niveau, ikke hard-kodet i Python. Og de kan "instantieres" for enhver enhed (medmindre du lægger brugerdefinerede begrænsninger, som er uden for EAV-Django ansvarsområde).
Navnene på attributter er defineret i relaterede skemaer. Dette kan føre til frygt for, at når et navn ændres, bliver koden kommer til at bryde. Faktisk er dette ikke er tilfældet navne er kun anvendes direkte til manuelle opslag. I alle andre tilfælde de opslag er konstrueret uden hårdt kodet navne, og den europæiske merværdi objekter er indbyrdes forbundet ved primære nøgler, ikke af navne. Navnene er til stede, hvis former, men de formularer genereres afhængigt aktuelle tilstand af metadata, så du sikkert kan omdøbe skemata. Hvad du kan bryde fra admin interface er typerne. Hvis du ændrer datatype et skema, vil alle dens egenskaber forbliver de samme, men vil bruge en anden kolonne til at gemme deres værdier. Når du gendanner datatype, tidligere lagrede værdier er synlige igen.
Se test for flere eksempler.
Datatyper
Metadata-drevet struktur udvider fleksibilitet, men indebærer nogle kompromisser. En af dem er forøget antal slutter (og derfor langsommere forespørgsler). En anden er færre datatyper. Teoretisk set kan vi støtte alle typer til rådighed for en datalagring, men i praksis vil det betyde, at skabe mange kolonner pr attribut med blot nogle få bliver brugt - præcis hvad vi forsøgte at undgå ved at bruge europæisk merværdi. Derfor EAV-Django understøtter kun nogle grundlæggende typer (selvom du kan udvide denne liste, hvis nødvendigt):
& Nbsp; * Schema.TYPE_TEXT, en TextField;
& Nbsp; * Schema.TYPE_FLOAT, en FloatField;
& Nbsp; * Schema.TYPE_DATE, en DateField;
& Nbsp; * Schema.TYPE_BOOL, en NullBooleanField;
& Nbsp; * Schema.TYPE_MANY for flere valg (dvs. lister over værdier).
Alle EAV attributter gemmes som poster i en tabel med unikke kombinationer af henvisninger til enheder og skemaer. (Entity refereres inden for rammerne contenttypes er skema refereres via fremmed nøgle.) Med andre ord kan der kun være én attribut med given enhed og skema. Skemaet er en definition af attribut. Skemaet definerer navn, titel, datatype og en række andre egenskaber, der gælder for enhver attribut i dette skema. Når vi adgang til eller søge EAV attributter, den europæiske merværdi maskiner bruger altid skemata som attributter metadata. Hvorfor? Fordi attribut navn er gemt i tilhørende skema, og værdien lagres i en kolonne af attributter bordet. Vi ved ikke, hvilken kolonne er det indtil vi ser på metadata.
I eksemplet ovenfor anførte vi har kun spillet med en tekst attribut. Alle andre typer opfører sig nøjagtig den samme, bortset fra TYPE_MANY. Den mange-til-mange er et særligt tilfælde, da det indebærer en ekstra model for valg. EAV-Django giver en abstrakt model, men kræver, at du definere en konkret model (f.eks Choice), og peg på det fra attributten model (dvs. sætte fremmed nøgle med navnet "valg"). Valget model vil også nødt til at pege på Schema. Tjek testene for eksempel

Hvad er nyt i denne udgivelse:.

• Opret / opdater / adgang: model forekomster giver Standart API til både & quot; ægte & quot; felter og EAV attributter. Den abstraktion, dog ikke stå i vejen og giver midler til at håndtere den underliggende ting.
• Forespørgsel: BaseEntityManager omfatter ensartet tilgang i filter () og udelukke () for at forespørge & quot; ægte & quot; og EAV attributter.
• Kan tilpasses skemaer for attributter.
• Admin: alle dynamiske egenskaber kan være repræsenteret og ændres i Django admin med ingen eller lille indsats (ved hjælp eav.admin.BaseEntityAdmin). Skemaer kan redigeres separat, som almindelige Django model objekter.
• facetter: facet søgning er et vigtigt element i online-butikker, kataloger osv Grundlæggende skal du bruge en formular, der repræsenterer en bestemt delmængde af model attributter med passende widgets og valg, således at brugeren kan vælge ønskelige værdier af nogle egenskaber, indsende formularen og få en liste med matchende poster. Generelt tilfælde Django-filter ville gøre, men det vil ikke fungere med EAV, så EAV-Django indeholder et komplet sæt af værktøjer til det.

Krav :

• Python
• Django