EAV-Django egy újrafelhasználható Django app, amely egy megvalósítása Entity-attribútum-érték adatmodell.
& Nbsp; Entity-attribútum-érték modellt (EAV), más néven objektum-attribútum-érték modell és nyitott sémát, amely a használt körülmények között, amikor az attribútumok száma (tulajdonságok, paraméterek), hogy lehet használni, hogy leírja a dolog (egy " szervezet "vagy" tárgy ") potenciálisan nagyon nagy, de ez a szám, hogy ténylegesen vonatkozik egy adott szervezet viszonylag szerény.
EAV-Django működik a hagyományos RDBMS (tesztelt SQLite és MySQL).
Prioritások
Az alkalmazás nőtt az online bolt projekt, így elég praktikus és nem csak tudományos kísérlet. A főbb prioritások:
& Nbsp; 1. rugalmasságát adatok,
& Nbsp; 2. hatékonyságát lekérdezések és
& Nbsp; 3. maximális karbantarthatósági szerkesztés nélkül a kódot.
Természetesen ez azt jelenti, kompromisszumok, és a cél az volt, hogy megtalálják a legkevésbé káros kombináció az általános esetben.
Jellemzők
Minden biztosított modell absztrakt, azaz EAV-Django nem tárol semmilyen információt saját táblázatokat. Ehelyett alapot nyújt a saját modellek, amelyek támogatják a EAV ki a dobozból.
Az EAV API tartalmazza:
& Nbsp; * Új / update / elérhetőség: modell eset azonban standart API mind az "igazi" mezők és EAV tulajdonítja. Az absztrakció, azonban nem állok az utadba, és biztosítja azt jelenti, hogy foglalkozik a mögöttes dolgokat.
& Nbsp; * Lekérdezés: BaseEntityManager tartalmazza egységes megközelítés filter (), és zárja ki () a lekérdezés "valós" és EAV attribútumok.
& Nbsp; * szabható sémák az attribútumokat.
& Nbsp; * Admin: az összes dinamikus jellemzők is képviselteti magát, és módosították az Django admin nélkül vagy kis erőfeszítéssel (a eav.admin.BaseEntityAdmin). Sémák lehet szerkeszteni külön-külön, mint a közönséges Django modell objektumokat.
& Nbsp; * Metszettel: facet keresési fontos jellemzője az online boltok, katalógusok, stb Alapvetően akkor kell egy űrlapot képviselő egy bizonyos részét modell attribútumok megfelelő widgetek és döntéseket, így a felhasználó választhat kívánatos értékei néhány tulajdonság, benyújtja A forma és kap egy listát a talált tételeket. Általános esetben django-szűrő lenne csinálni, de ez nem fog működni a EAV, így EAV-Django egy teljes eszközkészletet, hogy.
Példák
Nézzük meg az EAV-barát modell, hozzon létre egy EAV attribútum, és hogyan viselkedik. A "EAV attribútumok" Úgy értem ezeket az adatbázisban tárolt különálló tárgyak, de elérhető és keresett oly módon, mintha oszlopok a gazdálkodó táblázat:
a django.db import modellek
a eav.models import BaseEntity, BaseSchema, BaseAttribute
osztály Gyümölcs (BaseEntity):
& Nbsp; title = models.CharField (MAX_LENGTH = 50)
osztály séma (BaseSchema):
& Nbsp; menetben
osztály Attr (BaseAttribute):
& Nbsp; séma = models.ForeignKey (séma, related_name = 'attrs)
# Python shell:
# Létrehozunk attribútum, az "színes"
>>> Color = Schema.objects.create (
... Title = "Colour",
... Name = "color" # kihagyás feltölteni / slugify a címet
... Adattípus = Schema.TYPE_TEXT
...)
# Létre az egység
>>> E = Fruit.objects.create (title = "Apple", color = "green")
# Határozzák meg "valódi" és EAV attribútumok ugyanúgy
>>> E.title
"Apple"
>>> E.colour
"Zöld"
>>> E.save () # foglalkozik EAV attribútumok automatikusan
# Listát EAV attribútumok, mint Attr példányok
>>> E.attrs.all ()
[
# Keresési egy EAV attribútum, mintha egy közönséges téren
>>> Fruit.objects.filter (color = "sárga")
[
# Minden összetett kereséseket támogatott
>>> Fruit.objects.filter (colour__contains = "kiabálni")
[
Ne feledje, hogy el tudjuk érni, módosítására és lekérdezésére színt, mintha az egy igaz Entity területen, de ugyanakkor a nevét, típusát és még existance teljesen határozza meg a séma példányt. A séma objektum lehet értelmezni, mint egy osztály, és a kapcsolódó Attr tárgyak objektumai. Más szóval, sémaobjektumok olyanok, mint CharField, IntegerField és az ilyen, csak a megadott adatok szintjén, nem kódolva Python. És ők is "példányai" minden Entity (hacsak nem tesz egyedi korlátok, amelyek kívül esnek az EAV-Django felelősségi területét).
A nevét attribútumok meghatározott kapcsolódó sémák. Ez ahhoz vezethet, hogy attól tart, hogy ha egy neve megváltozik, a kód fog törni. Igazából nem ez a helyzet, mint neveket kizárólag közvetlenül alkalmazott kézi kereséseket. Minden más esetben a kereséseket megépítésük nélkül kódolva neveket, és a EAV objektumok állnak egymással elsődleges gombokkal, nem neveket. A nevek vannak jelen, ha formák, de a formák jönnek létre attól függően, jelenlegi állapotában metaadatok, így nyugodtan nevezd át a sémákat. Mit lehet megtörni az admin felület típusok. Ha megváltoztatja az adatok típusát a sémát, annak minden attribútumok ugyanaz marad, de lesz használni egy másik oszlop tárolja az értéküket. Ha visszaállítja a típusát, korábban tárolt értékek ismét láthatóvá.
Lásd tesztek további példákat.
Adattípusok
Metaadat-alapú struktúra kiterjeszti a rugalmasságot, de maga után vonja a kompromisszumokat. Az egyik a fokozott illesztések száma (és, következésképpen, lassabb lekérdezések). A másik az, kevesebb adattípusok. Elméletileg tudjuk támogatni minden adat esetében használható a tároló, de a gyakorlatban ez azt jelentené, amely nagyon sok oszlopot attribútumonkénti mindössze néhány használják - pontosan mit is igyekeznek elkerülni segítségével EAV. Ezért van az EAV-Django csak akkor támogatja valamilyen alapvető típusa (bár lehet kiterjeszteni ezt a listát, ha szükséges):
& Nbsp; * Schema.TYPE_TEXT, a TextField;
& Nbsp; * Schema.TYPE_FLOAT, a FloatField;
& Nbsp; * Schema.TYPE_DATE, a DateField;
& Nbsp; * Schema.TYPE_BOOL, a NullBooleanField;
& Nbsp; * Schema.TYPE_MANY számára több választási (azaz értékek listáját).
Minden EAV attribútumok tárolják a rekordok egy asztal egyedülálló kombinációja hivatkozások szervezetek és a sémákat. (Entity hivatkozik a contenttypes keret, a séma hivatkozik keresztül idegen kulcs.) Más szóval, nem lehet csak egy olyan attribútumot, adott entitás és séma. A séma meghatározása attribútum. A séma nevét, címét, az adatok típusát és számos egyéb tulajdonságai alkalmazni minden tulajdonsága ennek a sémának. Amikor elérni vagy keressen EAV attribútumokat, a EAV gép mindig használ sémákat, mint attribútumok metaadatokat. Miért? Mivel az attribútum neve tárolva van a kapcsolódó séma, és az érték eltárolódik egy oszlopában a attribútumok táblázat. Nem tudjuk, melyik oszlop ez, amíg nézzük metaadatokat.
Ebben a példában is fent van csak játszottam egy szöveges attribútum. Minden más típusú viselkedik pontosan ugyanaz, kivéve a TYPE_MANY. A sok-sok különleges eset, mert egy plusz modell döntéseket. EAV-Django egy absztrakt modellt, de megköveteli, hogy megadjuk a modell konkrét (pl Choice), és pont ez a tulajdonság modell (azaz fel az idegen kulcs neve "választás"). A választási modellhez is meg kell mutatni séma. Ellenőrizze a tesztek egy példát.
Mi az új ebben a kiadásban:
- / update / elérhetőség: modell eset azonban Standart API egyaránt & quot; igazi & quot; mezők és EAV attribútumokat. Az absztrakció, azonban nem állok az utadba, és biztosítja azt jelenti, hogy foglalkozik a mögöttes dolgokat.
- Lekérdezés: BaseEntityManager tartalmazza egységes megközelítés filter (), és zárja ki () a lekérdezés & quot; igazi & quot; és EAV attribútumok.
- szabható sémák az attribútumokat.
- Admin: az összes dinamikus jellemzők is képviselteti magát, és módosították az Django admin nélkül vagy kis erőfeszítéssel (a eav.admin.BaseEntityAdmin). Sémák lehet szerkeszteni külön-külön, mint a közönséges Django modell tárgyakat.
- Metszettel: facet keresési fontos jellemzője az online boltok, katalógusok, stb Alapvetően akkor kell egy űrlapot képviselő egy bizonyos részét modell attribútumok megfelelő widgetek és döntéseket, így a felhasználó választhat kívánatos értékei néhány tulajdonság, benyújtja A forma és kap egy listát a talált tételeket. Általános esetben django-szűrő lenne csinálni, de ez nem fog működni a EAV, így EAV-Django egy teljes eszközkészletet, hogy.
követelmények :
- Python
- Django
Hozzászólás nem található