EAV-Django

EAV-Django er en gjenbrukbar Django app som gir en implementering av Entity-Egenskap-Value datamodell.
& Nbsp; Entity-Egenskap-Value-modellen (EAV), også kjent som objekt-attributt-verdi-modellen og åpen skjema som brukes i tilfeller der antall attributter (egenskaper, parametre) som kan brukes til å beskrive en ting (en " enhet "eller" objekt ") er potensielt svært store, men antallet som faktisk vil gjelde for en gitt enhet er relativt beskjeden.
EAV-Django fungerer fint med tradisjonell RDBMS (testet på SQLite og MySQL).
Prioriteringer
Søknaden vokste fra en nettbutikk prosjekt, så det er ganske praktisk og ikke bare en akademisk øvelse. Hovedprioriteringene var:
& Nbsp; en. Fleksibiliteten av data,
& Nbsp; 2. effektiviteten av spørringer, og
& Nbsp; 3. maksimal vedlikehold uten å redigere koden.
Selvfølgelig dette innebærer avveininger, og målet var å finne den minst skadelige kombinasjon for det generelle tilfellet.
Spesifikasjoner
Alle følger modeller er abstrakt, dvs. EAV-Django lagrer ikke noen informasjon i sine egne tabeller. I stedet gir det et grunnlag for dine egne modeller som vil ha støtte for EAV ut av boksen.
EAV API inkluderer:
& Nbsp; * Lag / oppdater / tilgang: modell tilfeller gi standart API for både "ekte" felt og EAV attributter. Abstraksjon, men ikke stå i veien og gir midler til å håndtere de underliggende ting.
& Nbsp; * Query: BaseEntityManager omfatter helhetlig tilnærming i filter () og inkluderer () til å spørre "ekte" og EAV attributter.
& Nbsp; * Tilpasses schemata for attributter.
& Nbsp; * Admin: alle dynamiske egenskaper kan representeres og endres i Django admin med ingen eller liten innsats (med eav.admin.BaseEntityAdmin). Schemata kan redigeres separat, som ordinære Django modellobjektene.
& Nbsp; * fasetter: fasett søk er en viktig funksjon i nettbutikker, kataloger, etc. I utgangspunktet trenger du en form som representerer en bestemt undergruppe av modell attributter med passende widgets og valg, slik at brukeren kan velge ønskede verdiene for noen egenskaper, sende inn skjemaet og få en liste over samsvarende elementer. I generelle tilfellet django-filter ville gjøre, men det vil ikke fungere med EAV, så EAV-Django gir et komplett sett med verktøy for det.
Eksempler
La oss definere en EAV-vennlig modell, skape en EAV attributt og se hvordan den oppfører seg. Med "EAV attributter" Jeg mener de som er lagret i databasen som separate objekter, men åpnes og søkte på en slik måte som om de var kolonner i foretakets tabellen:
fra django.db importmodeller
fra eav.models import BaseEntity, BaseSchema, BaseAttribute
klasse Frukt (BaseEntity):
& Nbsp; title = models.CharField (MAX_LENGTH = 50)
klasse Schema (BaseSchema):
& Nbsp; pass
klasse Attr (BaseAttribute):
& Nbsp; skjema = models.ForeignKey (Schema, related_name = 'attrs')
# I Python shell:
# Define attributt som heter "farge"
>>> Color = Schema.objects.create (
... Title = "Farge",
... Name = 'farge' # utelate å befolke / slugify fra tittelen
... Datatype = Schema.TYPE_TEXT
...)
# Skape en enhet
>>> E = Fruit.objects.create (title = 'Apple', color = 'grønn')
# Definere "ekte" og EAV attributter på samme måte
>>> E.title
'Apple'
>>> E.colour
"Grønne"
>>> E.save () # avtaler med EAV attributter automatisk
# Liste EAV attributter som attr forekomster
>>> E.attrs.all ()
[]
# Søket ved en EAV attributt som om det var en vanlig felt
>>> Fruit.objects.filter (color = 'gul')
[]
# Alle sammensatte oppslag støttes
>>> Fruit.objects.filter (colour__contains = 'hyle')
[]
Merk at vi kan få tilgang til, endre og spørring farge som om det var en sann Entity felt, men samtidig sitt navn, type og selv eksistens er fullstendig definert av et Schema eksempel. En Schema objekt kan forstås som en klasse, og relaterte attr objekter er forekomstene. Med andre ord, Schema objekter er like charfield, IntegerField og slikt, bare definert på datanivå, ikke hardkodet i Python. Og de kan bli "startes" for enhver Entity (med mindre du setter definerte begrensninger som er utenfor EAV-Django ansvarsområde).
Navnene på attributtene er definert i relatert schemata. Dette kan føre til frykt for at når et navn er endret, er koden kommer til å bryte. Egentlig er dette ikke tilfelle som navnene er bare direkte brukes til manuelle oppslag. I alle andre tilfeller er oppslagene er konstruert uten hardkodet navn, og de EAV objektene henger sammen med primærnøkler, ikke ved navn. Navnene er til stede hvis former, men formene blir generert avhengig nåværende tilstand av metadata, slik at du trygt kan endre navn på schemata. Hva du kan bryte fra admin grensesnittet er de typene. Hvis du endre datatypen et skjema, vil alle sine attributter forbli den samme, men vil bruke en annen kolonne til å lagre sine verdier. Når du gjenoppretter datatypen, tidligere lagrede verdier er synlige igjen.
Se tester for flere eksempler.
Datatyper
Metadata-drevet strukturen strekker fleksibilitet, men innebærer noen avveininger. En av dem er økt antall joins (og derfor tregere spørringer). En annen er færre datatyper. Teoretisk sett kan vi støtter alle typer data tilgjengelig for en lagringsplass, men i praksis ville det bety å skape mange kolonner pr attributt med bare noen få blir brukt - nøyaktig hva vi prøvde å unngå ved hjelp EAV. Dette er grunnen til at EAV-Django støtter bare noen grunnleggende typer (men du kan utvide denne listen hvis nødvendig):
& 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 av verdier).
Alle EAV attributter lagres som poster i en tabell med unike kombinasjoner av referanser til enheter og schemata. (Entity er referert gjennom contenttypes rammeverket er skjema referert via fremmednøkkel.) Med andre ord, kan det bare være én attributt med gitt enhet og skjema. Skjemaet er en definisjon av attributt. Skjemaet definerer navn, tittel, datatype og en rekke andre egenskaper som gjelder for enhver egenskap av dette skjemaet. Når vi har tilgang til eller søke EAV attributter, EAV maskiner bruker alltid schemata som attributter metadata. Hvorfor? Fordi attributtnavnet er lagret i tilhørende skjema, og verdien lagres i en kolonne av attributter tabellen. Vi vet ikke hvilken kolonne det er før vi ser på metadata.
I eksempelet gitt ovenfor vi har bare spilt med et tekstfelt. Alle andre typer oppfører seg akkurat det samme bortsett TYPE_MANY. Den mange-til-mange er et spesielt tilfelle som det innebærer en ekstra modell for valg. EAV-Django gir en abstrakt modell, men krever at du definere en konkret modell (f.eks valg), og peker på det fra attributtet modellen (dvs. sette fremmednøkkel som heter "valg"). Choice-modellen vil også måtte peke på skjema. Sjekk testene for et eksempel

Hva er nytt i denne utgaven:.

• Lag / oppdater / tilgang: modell tilfeller gi standart API for både & quot; ekte & quot; felt og EAV attributter. Abstraksjon, men ikke stå i veien og gir midler til å håndtere de underliggende ting.
• spørring: BaseEntityManager omfatter helhetlig tilnærming i filter () og inkluderer () til å spørre & quot; ekte & quot; og EAV attributter.
• Passelig schemata for attributter.
• Admin: alle dynamiske egenskaper kan representeres og endres i Django admin med ingen eller liten innsats (med eav.admin.BaseEntityAdmin). Schemata kan redigeres separat, som ordinære Django modellobjektene.
• fasetter: fasett søk er en viktig funksjon i nettbutikker, kataloger, etc. I utgangspunktet trenger du en form som representerer en bestemt undergruppe av modell attributter med passende widgets og valg, slik at brukeren kan velge ønskede verdiene for noen egenskaper, sende inn skjemaet og få en liste over samsvarende elementer. I generelle tilfellet django-filter ville gjøre, men det vil ikke fungere med EAV, så EAV-Django gir et komplett sett med verktøy for det.

Krav :

• Python
• Django