[![Build Status](https://travis-ci.org/ambitioninc/django-entity.png)](https://travis-ci.org/ambitioninc/django-entity)
# Django Entity - [Release Notes](release_notes.md)
Django Entity is an app that provides Django projects with the ability to mirror their entities and entity relationships in a separate, well-contained and easily-accessible table.
Django Entity provides large-scale projects with the ability to better segregate their apps while minimizing the application-specific code in those apps that has to deal with entities and their relationships in the main project.
What is an entity? An entity is any model in your Django project. For example, an entity could be a Django User model or a Group of Users. Similarly, an entity relationship defines a super and sub relationship among different types of entities. For example, a Group would be a super entity of a User. The Django Entity app allows you to easily express this relationship in your model definition and sync it to a centralized place that is accessible by any other app in your project.
## A Use Case
Imagine that you have a Django project that defines many types of groupings of your users. For example, let's say in your enterprise project, you allow users to define their manager, their company position, and their regional branch location. Similarly, let's say that you have an app that can email groups of users based on their manager (or anyone who is under the managers of that manager), their position, or their region. This email app would likely have to know application-specific modeling of these relationships in order to be built. Similarly, doing things like querying for all users under a manager hierachy can be an expensive lookup depending on how it is modeled.
Using Django Entity, the email app could be written to take an Entity model rather than having to understand the complex relationships of each group. The Entity model passed to the email app could be a CompanyPosition model, and the get_sub_entities().is_any_type(ContentType.objects.get_for_model(User)) would return all of the User models under that CompanyPosition model. This allows the email app to be completely segregated from how the main project defines its relationships. Similarly, the query to obtain all User models under a CompanyPosition could be much more efficient than querying directly from the project (depending on how the project has its models structured).
## Getting Started - Configuring Entity Syncing
### Basic Use Case
Similar to Django's model admin, entities are configured by registering them with the Entity registry as follows:
```python
from entity import entity_registry
class Account(Model):
email = models.CharField(max_length=64)
entity_registry.register_entity(Account)
```
And just like that, the ``Account`` model is now synced to the ``Entity`` table every time an account is saved, deleted, or has any of its M2M fields updated.
### More Advanced Syncing Options
Django Entity would not be much if it only synced objects to a single ``Entity`` table. In order to take advantage of the power of mirroring relationships, the user must define a configuration for the entity that inherits ``EntityConfig``. A small example of this is below and extends our account model to have a ``Group`` foreign key.
```python
from entity import register_entity, EntityConfig, entity_registry
class Account(Model):
email = models.CharField(max_length=64)
group = models.ForeignKey(Group)
entity_registry.register_entity(Group)
@register_entity(Account)
class AccountConfig(EntityConfig):
def get_super_entities(self, model_obj):
return [model_obj.group]
```
In the above scenario, we mirrored the ``Group`` model using the default entity configuration. However, the ``Account`` model now uses a special configuration that inherits ``EntityConfig``. It overrides the ``get_super_entities`` function to return a list of all model objects that are super entities to the account. Once the account is synced, the user may then do various filtering on the relationships of accounts to groups (more on that later).
Note - in the above example, we also used the ``register_entity`` decorator, which is really just short notation for doing ``entity_registry.register_entity(model_class, entity_config_class)``.
Along with the ability to mirror relationships, the entity configuration can be extended to mirror metadata about an entity. For example, using the ``Account`` model in the previous example:
```python
@register_entity(Account)
class AccountConfig(EntityConfig):
def get_super_entities(self, model_obj):
return [model_obj.group]
def get_entity_meta(self, model_obj):
return {
'email': model_obj.email
}
```
With the above configuration, every account entity will have an entity_meta field (a JSON field) that has the email attribute mirrored as well. The metadata mirroring can be powerful for building generic apps on top of entities that need access to concrete fields of a concrete model (without having to prefetch all of the concrete models pointed to by the entities).
Along with metadata, entities come with the ability to mirror a ``display_name`` field in order to provide a human-readable name for the entity that can also be filtered in the database. By default, the ``display_name`` field uses the result of the ``unicode()`` function applied to the concrete model instance. The user may override this behavior by overriding the ``get_display_name`` method in the entity configuration.
Entities can also be configured to be active or inactive, and this is done by adding an ``get_is_active`` function to the config that returns ``True`` (the default value) if the entity is active and ``False`` otherwise.
### Advanced Syncing Continued - Entity Kinds
Entities have the ability to be labeled with their "kind" for advanced filtering capabilities. The entity kind allows a user to explicitly state what type of entity is being mirrored along with providing human-readable content about the entity kind. This is done by mirroring a unique ``name`` field and a ``display_name`` field in the ``EntityKind`` object that each ``Entity`` model points to.
By default, Django Entity will mirror the content type of the entity as its kind. The name field will be the ``app_label`` of the content type followed by a dot followed by the ``model`` of the content type. For cases where this name is not descriptive enough for the kind of the entity, the user has the ability to override the ``get_entity_kind`` function in the entity config. For example:
```python
@register_entity(Account)
class AccountConfig(EntityConfig):
def get_entity_kind(self, model_obj):
return (model_obj.email_domain, 'Email domain {0}'.format(model_obj.email_domain))
```
In the above case, the account entities are segregated into different kinds based on the domain of the email. The second value of the returned tuple provides a human-readable version of the kind that is being created.
### Even More Advanced Syncing - Watching Other Models
Underneath the hood, Django Entity is syncing up the mirrored Entity table when saves, deletes, and M2M updates are happening on the mirrored models. However, some models may actually depend on objects that are not pointed to by the immediate fields of the model. For example, assume that we have the following models:
```python
class Group(models.Model):
group_name = models.CharField()
class User(models.Model):
email = models.CharField()
groups = models.ManyToManyField(Group)
class Account(models.Model):
user = models.OneToOneField(User)
```
Now, assume that the ``Account`` model wants to add every ``Group`` model in the many to many of the ``User`` model as its super entity. This would be set up with the following config:
```python
entity_registry.register_entity(Group)
@register_entity(Account):
class AccountConfig(EntityConfig):
def get_super_e
没有合适的资源?快使用搜索试试~ 我知道了~
温馨提示
共38个文件
py:27个
txt:4个
pkg-info:2个
资源分类:Python库 所属语言:Python 资源全名:django-entity-1.16.0.tar.gz 资源来源:官方 安装方法:https://lanzao.blog.csdn.net/article/details/101784059
资源详情
资源评论
资源推荐
收起资源包目录
django-entity-1.16.0.tar.gz (38个子文件)
django-entity-1.16.0
MANIFEST.in 34B
PKG-INFO 23KB
LICENSE 1KB
setup.cfg 218B
setup.py 2KB
entity
models.py 18KB
apps.py 205B
management
commands
sync_entities.py 304B
__init__.py 0B
__init__.py 0B
tests
models.py 6KB
utils.py 1KB
__init__.py 0B
migrations
__init__.py 0B
0001_initial.py 5KB
sync_tests.py 35KB
registry_tests.py 6KB
model_tests.py 39KB
__init__.py 97B
migrations
0006_entity_relationship_unique.py 2KB
0002_entitykind_is_active.py 432B
__init__.py 0B
0005_remove_entitygroup_entities.py 358B
0004_auto_20150915_1747.py 433B
0003_auto_20150813_2234.py 1KB
0007_allentityproxy.py 517B
0001_initial.py 2KB
config.py 5KB
signal_handlers.py 4KB
version.py 23B
sync.py 9KB
README.md 19KB
django_entity.egg-info
PKG-INFO 23KB
requires.txt 195B
not-zip-safe 1B
SOURCES.txt 1KB
top_level.txt 7B
dependency_links.txt 1B
共 38 条
- 1
挣扎的蓝藻
- 粉丝: 13w+
- 资源: 15万+
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论0