EAV-Django

EAV-Django是一個可重用的Django的應用程序，提供了實體 - 屬性 - 值的數據模型的實現。
＆NBSP;實體 - 屬性 - 值模型（EAV），也被稱為是用來在環境對象的屬性值的模型和開放的架構，其中的屬性（屬性，參數），其可以用於描述一個物件的數目（“實體“或”對象“），是潛在的非常巨大的，但實際上將適用於給定的實體的數量是相對適度的。
EAV-Django的正常工作與傳統的RDBMS（在SQLite和MySQL的測試）。
優先
該應用程序從網上商店的項目增長，所以這是很實際的，而不僅僅是一個學術活動。主要優先事項是：
＆NBSP; 1。數據的靈活性，
＆NBSP; 2。查詢的效率，並
＆NBSP; 3。最大的可維護性無需編輯代碼。
當然，這意味著取捨，而目標是找到一般情況下，至少有害的組合。
產品特點
提供的所有車型都是抽象的，即EAV-Django不保存在自己的表中的任何信息。相反，它提供了自己的模型，將有EAV的支持開箱即用的基礎。
該EAV API包括：
＆NBSP; *創建/更新/訪問：模型實例提供了兩種“真實”字段和屬性EAV非標準API。抽象，但是，並沒有站在你的方式，並提供了手段來對付潛在的東西。
＆NBSP; *查詢：BaseEntityManager包括過濾器統一的方法（）和exclude（）查詢“真實”和EAV屬性。
＆NBSP; *可定制的圖式的屬性。
＆NBSP; *管理：所有的動態屬性可以表示和修改Django管理沒有或很少的努力（使用eav.admin.BaseEntityAdmin）。圖式可以單獨進行編輯，作為普通的Django模型對象。
＆NBSP; *方面：面搜索是在線商店，目錄等一個重要的功能基本上你將需要一個形式代表與相應的部件和選擇模型的某個子集的屬性，使用戶可以選擇一些屬性值可取的，提交的形式和獲得的匹配的項目的列表。在一般情況下，Django的過濾器會做，但它不會與EAV工作，所以EAV，Django提供了一套完整的該工具。
範例
讓我們來定義EAV友好的模式，創建一個EAV屬性，看看它是如何工作。由“EAV屬性”我指的是存儲在數據庫中作為單獨的對象，但訪問和搜索以這樣的方式，如果他們在該實體的表列：
從django.db進口車型
從eav.models進口BaseEntity，BaseSchema，BaseAttribute
類水果（BaseEntity）：
＆NBSP;標題= models.CharField（MAX_LENGTH = 50）
一流的架構（BaseSchema）：
＆NBSP;通
一流的Attr（BaseAttribute）：
＆NBSP;模式= models.ForeignKey（架構，related_name ='ATTRS“）
＃在Python外殼：
＃定義屬性命名為“色”
>>>顏色= Schema.objects.create（
...標題='顏色'，
...名稱='色'，＃省略填充/ slugify從標題
...數據類型= Schema.TYPE_TEXT
...）
＃創建一個實體
>>> E = Fruit.objects.create（標題='蘋果'，顏色=“綠色”）
＃定義“真實”和EAV屬性相同的方式
>>> e.title
'蘋果'
>>> e.colour
“綠色”
>>> e.save（）＃處理EAV自動屬性
＃列表EAV的屬性的Attr實例
>>> e.attrs.all（）
[<的Attr：蘋果：顏色“綠色”>]
由EAV屬性＃搜索，如果它是一個普通的場
>>> Fruit.objects.filter（顏色='黃'）
[<水果：蘋果>]
＃所有的複合查詢的支持
>>> Fruit.objects.filter（colour__contains ='吆喝'）
[<水果：蘋果>]
需要注意的是，我們可以訪問，修改和查詢的顏色，就好像它是一個真正實體的領域，但在同一時間它的名稱，類型和甚至存在性完全由一個模式實例定義。 Schema對象可以理解為一類，以及相關的Attr對象的實例。換句話說，方案對象是像CharField，IntegerField和這樣的，只有在數據級定義的，而不是硬編碼在Python。他們可以“實例”的任何實體（除非你把自定義的制約因素是EAV，Django的責任區以外）。
屬性的名稱在相關的圖式定義。這會導致人們擔心一旦一個名稱被改變時，所述代碼將要打破。實際上這是並非如此，因為名稱僅直接用於手工查找。在其他情況下，查詢是沒有硬編碼名稱構建和EAV對象是相通通過主鍵，而不是名字。該名稱是否存在，如果形式，但形式的產生依賴於元數據的當前狀態，這樣你就可以安全地重命名的圖式。你可以在管理界面突破是類型。如果您更改架構的數據類型，它的所有屬性將保持不變，但將使用另一列來存儲他們的價值觀。當你恢復的數據類型，以前存儲的值再次可見。
看到測試更多的例子。
數據類型
元數據驅動的結構，擴展的靈活性，但暗示一些取捨。其中之一是增加數目的連接（和，因此，較慢的查詢）。另一種是更少的數據類型。從理論上講，我們可以支持可用於存儲所有的數據類型，但在實踐中這將意味著只有幾個被用於創建每個屬性的列 - 正是我們試圖避免使用EAV。這就是為什麼EAV-的Django只支持一些基本的類型（儘管你可以根據需要擴展這個列表）：
＆NBSP; * Schema.TYPE_TEXT，一個TextField;
＆NBSP; * Schema.TYPE_FLOAT，一個FloatField;
＆NBSP; * Schema.TYPE_DATE，一個的DateField;
＆NBSP; * Schema.TYPE_BOOL，一個NullBooleanField;
＆NBSP; * Schema.TYPE_MANY多種選擇（值即列表）。
所有EAV屬性存儲作為記錄在表中引用實體和圖式的獨特組合。 （實體通過contenttypes框架引用，模式經由外鍵引用。）換句話說，有可能只有一個具有給定的實體和架構屬性。該架構是屬性的定義。該模式定義的名稱，標題，數據類型和數目應用於該模式的任何其他屬性的屬性。當我們訪問或搜索EAV屬性，在EAV機械始終使用大綱作為屬性的元數據​​。為什麼呢？因為屬性的名稱被存儲在相關的模式，並且該值被存儲在屬性表中的一列。我們不知道哪一列是，直到我們看到的元數據。
在上面我們提供的例子已經只打了一個文本屬性。所有其他類型的行為完全除TYPE_MANY相同。許多一對多是一個特例，因為它涉及到的選擇，一個額外的模型。 EAV，Django提供了一個抽象的模型，但需要你定義一個具體的模型（如選擇），並指向其從屬性模型（即把命名為“選擇”的外鍵）。在選擇模式也將有指向模式。檢查測試為例

什麼在此版本中是新的：

• 創建/更新/訪問：模型實例提供真正的＆QUOT;為＆QUOT非標準API;字段和EAV屬性。抽象，但是，並沒有站在你的方式，並提供了手段來對付潛在的東西。
• 查詢：BaseEntityManager包括過濾器統一的方法（）和排除（）查詢＆QUOT;真正的＆QUOT;和EAV屬性。
• 在自定義的圖式的屬性。
• 在管理：所有的動態屬性可以表示和修改Django管理沒有或很少的努力（使用eav.admin.BaseEntityAdmin）。圖式可以單獨進行編輯，作為普通的Django模型對象。
• 在構面：面搜索是在線商店，目錄等一個重要的功能基本上你將需要代表模型的某個子集與相應的部件和選擇屬性，以便用戶可以選擇一些屬性值可取的一種形式，提交的形式和獲得的匹配的項目的列表。在一般情況下，Django的過濾器會做，但它不會與EAV工作，所以EAV，Django提供了一套完整的該工具。

要求：

• 在Python中
• 在Django的