EAV-Django

EAV-Django è un app Django riutilizzabile che fornisce una implementazione del modello di dati Entity-Attribute-Valore.
& Nbsp; il modello Entity-Attribute-Value (EAV), noto anche come modello di oggetti-attributo-valore e lo schema aperto che viene utilizzato nei casi in cui il numero di attributi (proprietà, parametri) che possono essere utilizzati per descrivere una cosa (una " entità "o" oggetto ") è potenzialmente molto vasto, ma il numero che effettivamente applicare a un determinato soggetto è relativamente modesto.
EAV-Django funziona bene con RDBMS tradizionale (testato su SQLite e MySQL).
Priorità
L'applicazione è cresciuto da un progetto di negozio on-line, quindi è abbastanza pratico e non solo un esercizio accademico. Le principali priorità sono:
& Nbsp; 1. flessibilità di dati,
& Nbsp; 2. efficienza delle query, e
& Nbsp; 3. massima manutenibilità senza modificare il codice.
Naturalmente questo comporta compromessi, e l'obiettivo è stato quello di trovare la combinazione meno dannosa per il caso generale.
Caratteristiche
Tutti i modelli forniti sono astratti, cioè EAV-Django non memorizza le informazioni nelle proprie tabelle. Invece, fornisce una base per i propri modelli, che avrà il supporto per EAV out of the box.
L'API EAV comprende:
& Nbsp; * Creazione / aggiornamento / accesso: istanze di modello offrono API standart per entrambi i campi "reali" e attributi EAV. L'astrazione, però, non stanno nel vostro cammino e fornisce i mezzi per affrontare la roba sottostante.
& Nbsp; * Query: BaseEntityManager include approccio uniforme filtro () ed escludere () per interrogare "reale" e gli attributi EAV.
& Nbsp; * schemi personalizzabili per gli attributi.
& Nbsp; * Amministrazione: tutti gli attributi dinamici possono essere rappresentati e modificati in admin Django senza o con poco sforzo (con eav.admin.BaseEntityAdmin). Schemi possono essere editati separatamente, come normali oggetti del modello Django.
& Nbsp; * Sfaccettature: ricerca sfaccettatura è una caratteristica importante di negozi online, cataloghi, ecc Fondamentalmente avrete bisogno di una forma che rappresenta un certo sottoinsieme del modello di attributi con i widget e le scelte appropriate in modo che l'utente può scegliere i valori desiderabili di alcune proprietà, presentare la forma e ottenere un elenco di elementi corrispondenti. In caso generale django-filtro avrebbe fatto, ma non funziona con EAV, così EAV-Django fornisce un set completo di strumenti per questo.
Esempi
Definiamo un modello EAV-friendly, creare un attributo EAV e vedere come si comporta. Con "attributi EAV" intendo quelli memorizzati nel database come oggetti separati ma accessibili e cercato in un modo come se fossero le colonne nella tabella dell'entità:
da modelli di importazione django.db
da eav.models BaseEntity importazione, BaseSchema, BaseAttribute
Frutto di classe (BaseEntity):
& Nbsp; title = models.CharField (max_length = 50)
Classe Schema (BaseSchema):
& Nbsp; passaggio
classe Attr (BaseAttribute):
& Nbsp; schema = models.ForeignKey (Schema, related_name = 'attrs')
# In Python shell:
# Define attributo denominato "colore"
>>> Color = Schema.objects.create (
... Title = 'Colore',
... Name = 'color', # omettere per popolare / slugify dal titolo
... Datatype = Schema.TYPE_TEXT
...)
# Creare un'entità
>>> E = Fruit.objects.create (title = 'Apple', color = 'green')
# Definisce "reale" e EAV attributi allo stesso modo
>>> E.title
'Mela'
>>> E.colour
'Green'
>>> E.save () si occupa di EAV # attributi automaticamente
# Lista attributi EAV come istanze Attr
>>> E.attrs.all ()
[]
# Ricerca per un attributo EAV come se fosse un campo normale
>>> Fruit.objects.filter (color = 'giallo')
[]
# Tutte le ricerche composti sono supportati
>>> Fruit.objects.filter (colour__contains = 'urlare')
[]
Si noti che si può accedere, modificare e colore query come se fosse un vero e proprio campo Entità, ma allo stesso tempo il suo nome, il tipo e persino esistenza siamo completamente definito da un'istanza dello schema. Un oggetto schema può essere inteso come una classe, e gli oggetti Attr correlati sono le sue istanze. In altre parole, gli oggetti dello schema sono come CharField, IntegerField e tale, definita solo a livello di dati, non a livello di codice in Python. E possono essere "istanziati" per qualsiasi entità (a meno che non si mette vincoli personalizzati che sono al di fuori della zona di EAV-Django di responsabilità).
I nomi degli attributi sono definiti in schemi relativi. Questo può portare a timori che una volta che un nome è cambiato, il codice sta per rompere. In realtà questo non è il caso, come i nomi sono solo direttamente utilizzati per le ricerche manuali. In tutti gli altri casi, le ricerche sono costruiti senza nomi hard-coded, e gli oggetti EAV sono interconnessi da chiavi primarie, non da nomi. I nomi sono presenti, se le forme, ma le forme sono generate a seconda dello stato attuale dei metadati, in modo è possibile rinominare in modo sicuro gli schemi. Che cosa si può rompere con l'interfaccia di amministrazione è il tipo. Se si cambia il tipo di dati di uno schema, tutti i suoi attributi rimangono gli stessi, ma useranno un'altra colonna per memorizzare i loro valori. Quando si ripristina il tipo di dati, i valori precedentemente memorizzati sono ancora visibili.
Vedere test per ulteriori esempi.
Tipi di dati
Struttura metadati estende la flessibilità, ma comporta alcuni compromessi. Uno di loro è aumentato il numero di join (e, quindi, le query più lente). Un altro è un minor numero di tipi di dati. Teoricamente, siamo in grado di supportare tutti i tipi disponibili per la memorizzazione dei dati, ma in pratica vorrebbe dire creare molte colonne per attributo con pochi in uso - esattamente quello che stavamo cercando di evitare utilizzando EAV. Questo è il motivo EAV-Django supporta solo alcuni tipi di base (anche se è possibile estendere questo elenco se necessario):
& Nbsp; * Schema.TYPE_TEXT, un TextField;
& Nbsp; * Schema.TYPE_FLOAT, un FloatField;
& Nbsp; * Schema.TYPE_DATE, un DateField;
& Nbsp; * Schema.TYPE_BOOL, un NullBooleanField;
& Nbsp; * Schema.TYPE_MANY per scelte multiple (cioè liste di valori).
Tutti gli attributi EAV vengono memorizzati come record in una tabella con combinazioni uniche di riferimenti a entità e schemi. (Entity si fa riferimento attraverso il quadro ContentTypes, schema viene fatto riferimento tramite chiave esterna.) In altre parole, non ci può essere un solo attributo con determinata entità e schema. Lo schema è una definizione di attributo. Lo schema definisce nome, il titolo, il tipo di dati e una serie di altre proprietà che si applicano a qualsiasi attributo di questo schema. Quando si accede o cerchiamo attributi EAV, il macchinario EAV sempre utilizza schemi come metadati attributi. Perché? Poiché il nome dell'attributo viene memorizzato nello schema relativo, e il valore viene memorizzato in una colonna della tabella attributi. Non sappiamo quale colonna è fino guardiamo metadati.
Nell'esempio fornito sopra abbiamo giocato solo con un attributo di testo. Tutti gli altri tipi si comportano esattamente la stessa tranne per TYPE_MANY. Il molti-a-molti è un caso particolare in quanto si tratta di un modello in più per le scelte. EAV-Django fornisce un modello astratto, ma si richiede di definire un modello concreto (ad esempio scelta), e punto dal modello dell'attributo (cioè mettere chiave esterna denominata "scelta"). Il modello scelta dovrà anche puntare a schema. Controllare le prove per un esempio

Cosa c'è di nuovo in questa versione:.

• Crea / update / accesso: istanze modello forniscono standart API sia per & quot; reale & quot; campi e attributi EAV. L'astrazione, però, non stanno nel vostro cammino e fornisce i mezzi per affrontare la roba sottostante.
• Query: BaseEntityManager include approccio uniforme filtro () ed escludere () per interrogare & quot; reale & quot; e gli attributi EAV.
• schemi personalizzabile per gli attributi.
• Amministrazione: tutti gli attributi dinamici possono essere rappresentati e modificati in admin Django senza o con poco sforzo (con eav.admin.BaseEntityAdmin). Schemi può essere modificato separatamente, come normali oggetti del modello di Django.
• Sfaccettature: ricerca sfaccettatura è una caratteristica importante di negozi online, cataloghi, ecc Fondamentalmente avrete bisogno di una forma che rappresenta un certo sottoinsieme del modello di attributi con i widget e le scelte appropriate in modo che l'utente può scegliere i valori desiderabili di alcune proprietà, presentare la forma e ottenere un elenco di elementi corrispondenti. In caso generale django-filtro avrebbe fatto, ma non funziona con EAV, così EAV-Django fornisce un set completo di strumenti per questo.

Requisiti :

• Python
• Django