EAV-Django

EAV-Django är en återanvändbar Django app som ger en implementering av Entity-Attribut-Värde datamodell.
& Nbsp; Entity-Attribut-Värde modell (EAV), även känd som objektattributvärde modell och öppen plan som används i de fall då antalet attribut (egenskaper, parametrar) som kan användas för att beskriva en sak (en " enhet "eller" objekt ") är potentiellt mycket omfattande, men antalet som faktiskt kommer att gälla för en viss enhet är relativt blygsam.
EAV-Django fungerar bra med traditionella RDBMS (testat på SQLite och MySQL).
Prioriteringar
Ansökan växte från en webbshop projekt, så det är ganska praktiskt och inte bara en akademisk övning. De viktigaste prioriteringarna var:
& Nbsp; 1. flexibilitet av data,
& Nbsp; 2. effektivitet frågor, och
& Nbsp; 3. maximal underhåll utan att redigera koden.
Naturligtvis innebär detta kompromisser, och målet var att hitta den minst skadliga kombination för det allmänna fallet.
Egenskaper
Alla som modeller är abstrakta, dvs EAV-Django lagrar inte någon information i sina egna tabeller. Istället ger det en grund för dina egna modeller som kommer ha stöd för europeiskt mervärde ur lådan.
Den EAV API inkluderar:
& Nbsp; * Skapa / uppdatera / tillträde: modell instanser ger dart API för både "riktiga" fält och EAV attribut. Den abstraktion, dock inte stå i vägen och ger medel för att hantera den underliggande grejer.
& Nbsp; * Fråga: BaseEntityManager innehåller enhetlig strategi i filtret () och omfattar () för att fråga "riktiga" och EAV attribut.
& Nbsp; * Anpassnings scheman för attribut.
& Nbsp; * Admin: alla dynamiska attribut kan representeras och ändras i Django admin med ingen eller liten ansträngning (med eav.admin.BaseEntityAdmin). Scheman kan redigeras separat, som vanliga Django modellobjekt.
& Nbsp; * Facets: fasett Search är ett viktigt inslag i online-butiker, kataloger etc. I princip behöver du ett formulär som representerar en viss delmängd av modellen attribut med lämpliga widgets och val så att användaren kan välja önskvärda värden av vissa egenskaper, lämna formuläret och få en lista med matchande poster. I django-filter allmänna fallet skulle göra, men det kommer inte att fungera med EAV, så EAV-Django ger en komplett uppsättning verktyg för detta.
Exempel
Låt oss definiera en EAV vänlig modell, skapa en EAV attribut och se hur den beter sig. Med "EAV attribut" menar jag de som lagras i databasen som separata objekt vara åtkomligt och sökte på ett sådant sätt som om de vore kolumner i företagets tabell:
från django.db importmodeller
från eav.models import BaseEntity, BaseSchema, BaseAttribute
klass Frukt (BaseEntity):
& Nbsp; title = models.CharField (MAX_LENGTH = 50)
klass Schema (BaseSchema):
& Nbsp; pass
klass Attr (BaseAttribute):
& Nbsp; schema = models.ForeignKey (Schema, related_name = "attrs")
# I Python shell:
# Define attribut med namnet "färg"
>>> Color = Schema.objects.create (
... Title = 'Colour',
... Name = "färg", # omit att befolka / slugify från titeln
... Datatype = Schema.TYPE_TEXT
...)
# Skapa en enhet
>>> E = Fruit.objects.create (title = 'Apple', color = "green")
# Definiera "riktiga" och EAV attribut på samma sätt
>>> E.title
"Apple"
>>> E.colour
"Gröna"
>>> E.save () # behandlar EAV attribut automatiskt
# Lista EAV attribut som attr instanser
>>> E.attrs.all ()
[]
# Sökning genom ett EAV attribut som om det var en vanlig fält
>>> Fruit.objects.filter (color = "gula")
[]
# Alla sammansatta uppslag stöds
>>> Fruit.objects.filter (colour__contains = 'skrika')
[]
Observera att vi kan komma åt, ändra och fråge färg som om det var en sann Entity fält, men samtidigt dess namn, typ och även är existens helt definieras av en Schema instans. Ett schema objekt kan förstås som en klass, och relaterade attR objekt är dess instanser. Med andra ord, schemaobjekt är som Charfield, IntegerField och sådant, endast definierad på datanivå, inte hårdkodad i Python. Och de kan "instansieras" för någon Entity (såvida du sätter egna begränsningar som ligger utanför EAV-Django ansvarsområde).
Namnen på attributen definieras i tillhörande scheman. Detta kan leda till farhågor om att en gång per namn ändras, är koden kommer att bryta. Egentligen är detta inte fallet eftersom namnen endast används direkt för manuella sökningar. I alla andra fall uppslag är konstruerade utan hårdkodade namn, och det europeiska mervärdet objekten är sammanlänkade genom primärnycklar, inte genom namn. Namnen är närvarande om former, men formerna genereras beroende på aktuell status för metadata, så att du kan byta namn på scheman. Vad du kan bryta från admin-gränssnittet är typerna. Om du ändrar datatyp ett schema, kommer alla dess attribut är desamma men kommer att använda en annan kolumn för att lagra sina värderingar. När du åter datatyp, tidigare lagrade värden syns igen.
Se tester för fler exempel.
Datatyper
Metadata driven struktur sträcker flexibilitet men innebär vissa kompromisser. En av dem är ökad Antalet föreningar (och därmed långsammare frågor). En annan är färre datatyper. Teoretiskt kan vi stödja alla datatyper som en förvaring, men i praktiken skulle det innebära att skapa många kolumner per attribut med bara några används - exakt vad vi försökte undvika genom att använda EAV. Detta är anledningen till EAV-Django stöder endast vissa grundläggande typer (även om du kan utöka denna lista om det behövs):
& Nbsp; * Schema.TYPE_TEXT, ett Textfield;
& Nbsp; * Schema.TYPE_FLOAT, en FloatField;
& Nbsp; * Schema.TYPE_DATE, en DateField;
& Nbsp; * Schema.TYPE_BOOL, en NullBooleanField;
& Nbsp; * Schema.TYPE_MANY för flera val (dvs. listor av värden).
Alla EAV attribut lagras som poster i en tabell med unika kombinationer av referenser till enheter och scheman. (Entity refereras genom ramverket contenttypes, är schemat refereras via främmande nyckel.) Med andra ord, kan det bara finnas ett attribut med viss enhet och schema. Schemat är en definition av attribut. Schemat definierar namn, titel, datatyp och ett antal andra egenskaper som gäller för alla attribut för detta schema. När vi åt eller söka EAV attribut, det europeiska mervärdet maskiner använder alltid scheman som attribut metadata. Varför? Eftersom attributets namn lagras i tillhörande schemat, och värdet lagras i en kolumn i tabellen attribut. Vi vet inte vilken kolumn det är tills vi tittar på metadata.
I exemplet ovan har vi bara spelat med en textattribut. Alla andra typer beter exakt samma utom för TYPE_MANY. Den många-till-många är ett specialfall eftersom det innebär en extra modell för val. EAV-Django ger en abstrakt modell men kräver att du definierar en konkret modell (t.ex. Val), och pekar på det från attributmodell (dvs sätta främmande nyckel som heter "val"). Valet Modellen måste också peka på schemat. Kolla testerna för ett exempel

Vad är nytt i den här versionen:.

• Skapa / uppdatera / tillträde: modell instanser ger dart API för både & quot; riktiga & quot; fält och EAV attribut. Den abstraktion, dock inte stå i vägen och ger medel för att hantera den underliggande grejer.
• Fråga: BaseEntityManager innehåller enhetlig strategi i filtret () och omfattar () för att fråga & quot; riktiga & quot; och EAV attribut.
• Anpassnings scheman för attribut.
• Admin: alla dynamiska attribut kan representeras och ändras i Django admin med ingen eller liten ansträngning (med eav.admin.BaseEntityAdmin). Scheman kan redigeras separat, som vanliga Django modellobjekt.
• Facets: fasett Search är ett viktigt inslag i online-butiker, kataloger etc. I princip behöver du ett formulär som representerar en viss delmängd av modellen attribut med lämpliga widgets och val så att användaren kan välja önskvärda värden av vissa egenskaper, lämna formuläret och få en lista med matchande poster. I django-filter allmänna fallet skulle göra, men det kommer inte att fungera med EAV, så EAV-Django ger en komplett uppsättning verktyg för det.

Krav :

• Python
• Django