django-dynamic-initial-data 2.1.0__tar.gz → 3.0.0__tar.gz

{django-dynamic-initial-data-2.1.0 → django_dynamic_initial_data-3.0.0}/LICENSE

@@ -1,20 +1,20 @@
-The MIT License (MIT)
-
-Copyright (c) 2014 Ambition
-
-Permission is hereby granted, free of charge, to any person obtaining a copy of
-this software and associated documentation files (the "Software"), to deal in
-the Software without restriction, including without limitation the rights to
-use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
-the Software, and to permit persons to whom the Software is furnished to do so,
-subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
-FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
-COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
-IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
-CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+The MIT License (MIT)
+
+Copyright (c) 2014 Ambition
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of
+this software and associated documentation files (the "Software"), to deal in
+the Software without restriction, including without limitation the rights to
+use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
+the Software, and to permit persons to whom the Software is furnished to do so,
+subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
+FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
+COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
+IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

{django-dynamic-initial-data-2.1.0 → django_dynamic_initial_data-3.0.0}/MANIFEST.in

@@ -1,2 +1,3 @@
-include README.md
-include LICENSE
+include README.md
+include LICENSE
+recursive-include requirements *

django_dynamic_initial_data-3.0.0/PKG-INFO

@@ -0,0 +1,156 @@
+Metadata-Version: 2.4
+Name: django-dynamic-initial-data
+Version: 3.0.0
+Summary: Dynamic initial data fixtures for Django apps
+Home-page: https://github.com/ambitioninc/django-dynamic-initial-data
+Author: 
+Author-email: opensource@ambition.com
+License: MIT
+Keywords: Django fixtures
+Classifier: Programming Language :: Python
+Classifier: Programming Language :: Python :: 3.10
+Classifier: Programming Language :: Python :: 3.11
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Programming Language :: Python :: 3.13
+Classifier: Programming Language :: Python :: 3.14
+Classifier: Intended Audience :: Developers
+Classifier: License :: OSI Approved :: MIT License
+Classifier: Operating System :: OS Independent
+Classifier: Framework :: Django
+Classifier: Framework :: Django :: 5.2
+Classifier: Framework :: Django :: 6.0
+Requires-Python: >=3.10
+Description-Content-Type: text/markdown
+License-File: LICENSE
+Requires-Dist: Django>=5.2
+Requires-Dist: django-manager-utils>=4.0.0
+Dynamic: author-email
+Dynamic: classifier
+Dynamic: description
+Dynamic: description-content-type
+Dynamic: home-page
+Dynamic: keywords
+Dynamic: license
+Dynamic: license-file
+Dynamic: requires-dist
+Dynamic: requires-python
+Dynamic: summary
+
+[![Build Status](https://travis-ci.org/ambitioninc/django-dynamic-initial-data.png)](https://travis-ci.org/ambitioninc/django-dynamic-initial-data)
+
+## Django Initial Data
+
+Django Dynamic Initial Data is a `django>=1.6` and *postgresql* only app that helps solve the problem of initializing data for apps with
+dependencies and other conditional data. Rather than having static fixtures for each app, the initial data
+can be created and updated dynamically. Furthermore, Django Dynamic Initial Data also handles when objects are
+deleted from initial data, a feature that Django's initial data fixture system lacks.
+
+## Table of Contents
+
+1. [Installation] (#installation)
+2. [A Brief Overview] (#a-brief-overview)
+3. [Example] (#example)
+4. [Handling Deletions](#handling-deletions)
+
+## Installation
+To install Django Dynamic Initial Data:
+
+```shell
+pip install django-dynamic-initial-data
+```
+
+Add Django Dynamic Initial Data to your `INSTALLED_APPS` to get started:
+
+settings.py
+```python
+INSTALLED_APPS = (
+    'dynamic_initial_data',
+)
+```
+
+## A Brief Overview
+
+A management command `update_initial_data` is provided which will try to update all `INSTALLED_APPS`. This
+command is intended to be called as part of the deployment process of your app. Any missing dependencies
+will raise an `InitialDataMissingApp` exception and any circular dependencies will raise an
+`InitialDataCircularDependency` exception.
+
+Any app needing to define initial data needs a file called `initial_data.py` inside of a `fixtures`
+directory. This will look like `{app_name}/fixtures/initial_data.py`. Don't forget to include
+the `__init__.py` file in the fixtures directory. `initial_data.py` must define a class `InitialData`
+that inherits from `BaseInitialData`.
+
+When apps are being initialized, each `InitialData` class is instantiated and `update_initial_data` is called.
+If `update_initial_data` is not implemented, then a `NotImplementedError` will be raised.
+
+Any dependencies should be included in a list called `dependencies`. Each dependency is a string
+of the app name as defined in `INSTALLED_APPS`.
+
+## Example:
+
+```python
+from dynamic_initial_data.base import BaseInitialData
+
+class InitialData(BaseInitialData):
+    dependencies = ['my_first_app', 'my.second.app']
+
+    def update_initial_data(self):
+        model_obj, created = TestModel.objects.upsert(int_field=5, defaults={'float_field': 2.0})
+
+        TestModel.objects.bulk_upsert([
+            TestModel(float_field=1.0, char_field='1', int_field=1),
+            TestModel(float_field=2.0, char_field='2', int_field=2),
+            TestModel(float_field=3.0, char_field='3', int_field=3),
+        ], ['int_field'], ['char_field'])
+```
+In this example, the `update_initial_data` method will be called for `my_first_app` (following any dependencies first),
+and then for `my.second.app`, before finally calling `update_initial_data` on this class. Again, this can be executed by calling
+
+```
+python manage.py update_initial_data
+```
+
+Similarly, to only initialize a single app, use
+
+```
+python manage.py update_initial_data --app 'app_path'
+```
+
+Documentation on using `upsert` and `bulk_upsert` can be found below:
+- https://github.com/ambitioninc/django-manager-utils#upsert
+- https://github.com/ambitioninc/django-manager-utils#bulk_upsert
+
+## Handling Deletions
+One difficulty when specifying initial data in Django apps is the inability to deploy initial data to your project and then subsequently remove any initial data fixtures. If one removes an object in an initial_data.json file, Django does not handle its deletion next time it is deployed, which can cause headaches with lingering objects.
+
+Django Dynamic Initial Data fixes this problem by allowing the user to either:
+
+1. Return all managed initial data objects as an array from the update_initial_data function.
+2. Explicitly register objects for deletion with the register_for_deletion(*model_objs) method.
+
+Note that it is up to the user to be responsible for always registering every object every time, regardless if the object was updated or created by the initial data process. Doing this allows Django Dynamic Initial Data to remove any objects that were previosly managed. For example, assume you have an InitialData class that manages two users with the user names "hello" and "world".
+
+```python
+from dynamic_initial_data.base import BaseInitialData
+
+class InitialData(BaseInitialData):
+    def update_initial_data(self):
+        hello = Account.objects.get_or_create(name='hello')
+        world = Account.objects.get_or_create(name='world')
+        # register the accounts for deletion
+        self.register_for_deletion(hello, world)
+```
+
+After this code is created, the initial data process now owns the "hello" and "world" account objects. If these objects are not registered for deletion in subsequent versions of the code, they will be deleted when the initial data process executes. For example, assume the first piece of code executed and then the user executed this piece of code:
+
+```python
+from dynamic_initial_data.base import BaseInitialData
+
+class InitialData(BaseInitialData):
+    def update_initial_data(self):
+        world = Account.objects.get_or_create(name='world')
+        # register the accounts for deletion
+        self.register_for_deletion(world)
+```
+
+When this piece of code executes, the previous "hello" account would then be deleted since the initial data process no longer owns it. And don't worry, if it was already deleted by another process, the deletion will not throw an error.

{django-dynamic-initial-data-2.1.0 → django_dynamic_initial_data-3.0.0}/README.md

@@ -1,118 +1,118 @@
-[![Build Status](https://travis-ci.org/ambitioninc/django-dynamic-initial-data.png)](https://travis-ci.org/ambitioninc/django-dynamic-initial-data)
-
-## Django Initial Data
-
-Django Dynamic Initial Data is a `django>=1.6` and *postgresql* only app that helps solve the problem of initializing data for apps with
-dependencies and other conditional data. Rather than having static fixtures for each app, the initial data
-can be created and updated dynamically. Furthermore, Django Dynamic Initial Data also handles when objects are
-deleted from initial data, a feature that Django's initial data fixture system lacks.
-
-## Table of Contents
-
-1. [Installation] (#installation)
-2. [A Brief Overview] (#a-brief-overview)
-3. [Example] (#example)
-4. [Handling Deletions](#handling-deletions)
-
-## Installation
-To install Django Dynamic Initial Data:
-
-```shell
-pip install django-dynamic-initial-data
-```
-
-Add Django Dynamic Initial Data to your `INSTALLED_APPS` to get started:
-
-settings.py
-```python
-INSTALLED_APPS = (
-    'dynamic_initial_data',
-)
-```
-
-## A Brief Overview
-
-A management command `update_initial_data` is provided which will try to update all `INSTALLED_APPS`. This
-command is intended to be called as part of the deployment process of your app. Any missing dependencies
-will raise an `InitialDataMissingApp` exception and any circular dependencies will raise an
-`InitialDataCircularDependency` exception.
-
-Any app needing to define initial data needs a file called `initial_data.py` inside of a `fixtures`
-directory. This will look like `{app_name}/fixtures/initial_data.py`. Don't forget to include
-the `__init__.py` file in the fixtures directory. `initial_data.py` must define a class `InitialData`
-that inherits from `BaseInitialData`.
-
-When apps are being initialized, each `InitialData` class is instantiated and `update_initial_data` is called.
-If `update_initial_data` is not implemented, then a `NotImplementedError` will be raised.
-
-Any dependencies should be included in a list called `dependencies`. Each dependency is a string
-of the app name as defined in `INSTALLED_APPS`.
-
-## Example:
-
-```python
-from dynamic_initial_data.base import BaseInitialData
-
-class InitialData(BaseInitialData):
-    dependencies = ['my_first_app', 'my.second.app']
-
-    def update_initial_data(self):
-        model_obj, created = TestModel.objects.upsert(int_field=5, defaults={'float_field': 2.0})
-
-        TestModel.objects.bulk_upsert([
-            TestModel(float_field=1.0, char_field='1', int_field=1),
-            TestModel(float_field=2.0, char_field='2', int_field=2),
-            TestModel(float_field=3.0, char_field='3', int_field=3),
-        ], ['int_field'], ['char_field'])
-```
-In this example, the `update_initial_data` method will be called for `my_first_app` (following any dependencies first),
-and then for `my.second.app`, before finally calling `update_initial_data` on this class. Again, this can be executed by calling
-
-```
-python manage.py update_initial_data
-```
-
-Similarly, to only initialize a single app, use
-
-```
-python manage.py update_initial_data --app 'app_path'
-```
-
-Documentation on using `upsert` and `bulk_upsert` can be found below:
-- https://github.com/ambitioninc/django-manager-utils#upsert
-- https://github.com/ambitioninc/django-manager-utils#bulk_upsert
-
-## Handling Deletions
-One difficulty when specifying initial data in Django apps is the inability to deploy initial data to your project and then subsequently remove any initial data fixtures. If one removes an object in an initial_data.json file, Django does not handle its deletion next time it is deployed, which can cause headaches with lingering objects.
-
-Django Dynamic Initial Data fixes this problem by allowing the user to either:
-
-1. Return all managed initial data objects as an array from the update_initial_data function.
-2. Explicitly register objects for deletion with the register_for_deletion(*model_objs) method.
-
-Note that it is up to the user to be responsible for always registering every object every time, regardless if the object was updated or created by the initial data process. Doing this allows Django Dynamic Initial Data to remove any objects that were previosly managed. For example, assume you have an InitialData class that manages two users with the user names "hello" and "world".
-
-```python
-from dynamic_initial_data.base import BaseInitialData
-
-class InitialData(BaseInitialData):
-    def update_initial_data(self):
-        hello = Account.objects.get_or_create(name='hello')
-        world = Account.objects.get_or_create(name='world')
-        # register the accounts for deletion
-        self.register_for_deletion(hello, world)
-```
-
-After this code is created, the initial data process now owns the "hello" and "world" account objects. If these objects are not registered for deletion in subsequent versions of the code, they will be deleted when the initial data process executes. For example, assume the first piece of code executed and then the user executed this piece of code:
-
-```python
-from dynamic_initial_data.base import BaseInitialData
-
-class InitialData(BaseInitialData):
-    def update_initial_data(self):
-        world = Account.objects.get_or_create(name='world')
-        # register the accounts for deletion
-        self.register_for_deletion(world)
-```
-
+[![Build Status](https://travis-ci.org/ambitioninc/django-dynamic-initial-data.png)](https://travis-ci.org/ambitioninc/django-dynamic-initial-data)
+
+## Django Initial Data
+
+Django Dynamic Initial Data is a `django>=1.6` and *postgresql* only app that helps solve the problem of initializing data for apps with
+dependencies and other conditional data. Rather than having static fixtures for each app, the initial data
+can be created and updated dynamically. Furthermore, Django Dynamic Initial Data also handles when objects are
+deleted from initial data, a feature that Django's initial data fixture system lacks.
+
+## Table of Contents
+
+1. [Installation] (#installation)
+2. [A Brief Overview] (#a-brief-overview)
+3. [Example] (#example)
+4. [Handling Deletions](#handling-deletions)
+
+## Installation
+To install Django Dynamic Initial Data:
+
+```shell
+pip install django-dynamic-initial-data
+```
+
+Add Django Dynamic Initial Data to your `INSTALLED_APPS` to get started:
+
+settings.py
+```python
+INSTALLED_APPS = (
+    'dynamic_initial_data',
+)
+```
+
+## A Brief Overview
+
+A management command `update_initial_data` is provided which will try to update all `INSTALLED_APPS`. This
+command is intended to be called as part of the deployment process of your app. Any missing dependencies
+will raise an `InitialDataMissingApp` exception and any circular dependencies will raise an
+`InitialDataCircularDependency` exception.
+
+Any app needing to define initial data needs a file called `initial_data.py` inside of a `fixtures`
+directory. This will look like `{app_name}/fixtures/initial_data.py`. Don't forget to include
+the `__init__.py` file in the fixtures directory. `initial_data.py` must define a class `InitialData`
+that inherits from `BaseInitialData`.
+
+When apps are being initialized, each `InitialData` class is instantiated and `update_initial_data` is called.
+If `update_initial_data` is not implemented, then a `NotImplementedError` will be raised.
+
+Any dependencies should be included in a list called `dependencies`. Each dependency is a string
+of the app name as defined in `INSTALLED_APPS`.
+
+## Example:
+
+```python
+from dynamic_initial_data.base import BaseInitialData
+
+class InitialData(BaseInitialData):
+    dependencies = ['my_first_app', 'my.second.app']
+
+    def update_initial_data(self):
+        model_obj, created = TestModel.objects.upsert(int_field=5, defaults={'float_field': 2.0})
+
+        TestModel.objects.bulk_upsert([
+            TestModel(float_field=1.0, char_field='1', int_field=1),
+            TestModel(float_field=2.0, char_field='2', int_field=2),
+            TestModel(float_field=3.0, char_field='3', int_field=3),
+        ], ['int_field'], ['char_field'])
+```
+In this example, the `update_initial_data` method will be called for `my_first_app` (following any dependencies first),
+and then for `my.second.app`, before finally calling `update_initial_data` on this class. Again, this can be executed by calling
+
+```
+python manage.py update_initial_data
+```
+
+Similarly, to only initialize a single app, use
+
+```
+python manage.py update_initial_data --app 'app_path'
+```
+
+Documentation on using `upsert` and `bulk_upsert` can be found below:
+- https://github.com/ambitioninc/django-manager-utils#upsert
+- https://github.com/ambitioninc/django-manager-utils#bulk_upsert
+
+## Handling Deletions
+One difficulty when specifying initial data in Django apps is the inability to deploy initial data to your project and then subsequently remove any initial data fixtures. If one removes an object in an initial_data.json file, Django does not handle its deletion next time it is deployed, which can cause headaches with lingering objects.
+
+Django Dynamic Initial Data fixes this problem by allowing the user to either:
+
+1. Return all managed initial data objects as an array from the update_initial_data function.
+2. Explicitly register objects for deletion with the register_for_deletion(*model_objs) method.
+
+Note that it is up to the user to be responsible for always registering every object every time, regardless if the object was updated or created by the initial data process. Doing this allows Django Dynamic Initial Data to remove any objects that were previosly managed. For example, assume you have an InitialData class that manages two users with the user names "hello" and "world".
+
+```python
+from dynamic_initial_data.base import BaseInitialData
+
+class InitialData(BaseInitialData):
+    def update_initial_data(self):
+        hello = Account.objects.get_or_create(name='hello')
+        world = Account.objects.get_or_create(name='world')
+        # register the accounts for deletion
+        self.register_for_deletion(hello, world)
+```
+
+After this code is created, the initial data process now owns the "hello" and "world" account objects. If these objects are not registered for deletion in subsequent versions of the code, they will be deleted when the initial data process executes. For example, assume the first piece of code executed and then the user executed this piece of code:
+
+```python
+from dynamic_initial_data.base import BaseInitialData
+
+class InitialData(BaseInitialData):
+    def update_initial_data(self):
+        world = Account.objects.get_or_create(name='world')
+        # register the accounts for deletion
+        self.register_for_deletion(world)
+```
+
 When this piece of code executes, the previous "hello" account would then be deleted since the initial data process no longer owns it. And don't worry, if it was already deleted by another process, the deletion will not throw an error.

django_dynamic_initial_data-3.0.0/django_dynamic_initial_data.egg-info/PKG-INFO

@@ -0,0 +1,156 @@
+Metadata-Version: 2.4
+Name: django-dynamic-initial-data
+Version: 3.0.0
+Summary: Dynamic initial data fixtures for Django apps
+Home-page: https://github.com/ambitioninc/django-dynamic-initial-data
+Author: 
+Author-email: opensource@ambition.com
+License: MIT
+Keywords: Django fixtures
+Classifier: Programming Language :: Python
+Classifier: Programming Language :: Python :: 3.10
+Classifier: Programming Language :: Python :: 3.11
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Programming Language :: Python :: 3.13
+Classifier: Programming Language :: Python :: 3.14
+Classifier: Intended Audience :: Developers
+Classifier: License :: OSI Approved :: MIT License
+Classifier: Operating System :: OS Independent
+Classifier: Framework :: Django
+Classifier: Framework :: Django :: 5.2
+Classifier: Framework :: Django :: 6.0
+Requires-Python: >=3.10
+Description-Content-Type: text/markdown
+License-File: LICENSE
+Requires-Dist: Django>=5.2
+Requires-Dist: django-manager-utils>=4.0.0
+Dynamic: author-email
+Dynamic: classifier
+Dynamic: description
+Dynamic: description-content-type
+Dynamic: home-page
+Dynamic: keywords
+Dynamic: license
+Dynamic: license-file
+Dynamic: requires-dist
+Dynamic: requires-python
+Dynamic: summary
+
+[![Build Status](https://travis-ci.org/ambitioninc/django-dynamic-initial-data.png)](https://travis-ci.org/ambitioninc/django-dynamic-initial-data)
+
+## Django Initial Data
+
+Django Dynamic Initial Data is a `django>=1.6` and *postgresql* only app that helps solve the problem of initializing data for apps with
+dependencies and other conditional data. Rather than having static fixtures for each app, the initial data
+can be created and updated dynamically. Furthermore, Django Dynamic Initial Data also handles when objects are
+deleted from initial data, a feature that Django's initial data fixture system lacks.
+
+## Table of Contents
+
+1. [Installation] (#installation)
+2. [A Brief Overview] (#a-brief-overview)
+3. [Example] (#example)
+4. [Handling Deletions](#handling-deletions)
+
+## Installation
+To install Django Dynamic Initial Data:
+
+```shell
+pip install django-dynamic-initial-data
+```
+
+Add Django Dynamic Initial Data to your `INSTALLED_APPS` to get started:
+
+settings.py
+```python
+INSTALLED_APPS = (
+    'dynamic_initial_data',
+)
+```
+
+## A Brief Overview
+
+A management command `update_initial_data` is provided which will try to update all `INSTALLED_APPS`. This
+command is intended to be called as part of the deployment process of your app. Any missing dependencies
+will raise an `InitialDataMissingApp` exception and any circular dependencies will raise an
+`InitialDataCircularDependency` exception.
+
+Any app needing to define initial data needs a file called `initial_data.py` inside of a `fixtures`
+directory. This will look like `{app_name}/fixtures/initial_data.py`. Don't forget to include
+the `__init__.py` file in the fixtures directory. `initial_data.py` must define a class `InitialData`
+that inherits from `BaseInitialData`.
+
+When apps are being initialized, each `InitialData` class is instantiated and `update_initial_data` is called.
+If `update_initial_data` is not implemented, then a `NotImplementedError` will be raised.
+
+Any dependencies should be included in a list called `dependencies`. Each dependency is a string
+of the app name as defined in `INSTALLED_APPS`.
+
+## Example:
+
+```python
+from dynamic_initial_data.base import BaseInitialData
+
+class InitialData(BaseInitialData):
+    dependencies = ['my_first_app', 'my.second.app']
+
+    def update_initial_data(self):
+        model_obj, created = TestModel.objects.upsert(int_field=5, defaults={'float_field': 2.0})
+
+        TestModel.objects.bulk_upsert([
+            TestModel(float_field=1.0, char_field='1', int_field=1),
+            TestModel(float_field=2.0, char_field='2', int_field=2),
+            TestModel(float_field=3.0, char_field='3', int_field=3),
+        ], ['int_field'], ['char_field'])
+```
+In this example, the `update_initial_data` method will be called for `my_first_app` (following any dependencies first),
+and then for `my.second.app`, before finally calling `update_initial_data` on this class. Again, this can be executed by calling
+
+```
+python manage.py update_initial_data
+```
+
+Similarly, to only initialize a single app, use
+
+```
+python manage.py update_initial_data --app 'app_path'
+```
+
+Documentation on using `upsert` and `bulk_upsert` can be found below:
+- https://github.com/ambitioninc/django-manager-utils#upsert
+- https://github.com/ambitioninc/django-manager-utils#bulk_upsert
+
+## Handling Deletions
+One difficulty when specifying initial data in Django apps is the inability to deploy initial data to your project and then subsequently remove any initial data fixtures. If one removes an object in an initial_data.json file, Django does not handle its deletion next time it is deployed, which can cause headaches with lingering objects.
+
+Django Dynamic Initial Data fixes this problem by allowing the user to either:
+
+1. Return all managed initial data objects as an array from the update_initial_data function.
+2. Explicitly register objects for deletion with the register_for_deletion(*model_objs) method.
+
+Note that it is up to the user to be responsible for always registering every object every time, regardless if the object was updated or created by the initial data process. Doing this allows Django Dynamic Initial Data to remove any objects that were previosly managed. For example, assume you have an InitialData class that manages two users with the user names "hello" and "world".
+
+```python
+from dynamic_initial_data.base import BaseInitialData
+
+class InitialData(BaseInitialData):
+    def update_initial_data(self):
+        hello = Account.objects.get_or_create(name='hello')
+        world = Account.objects.get_or_create(name='world')
+        # register the accounts for deletion
+        self.register_for_deletion(hello, world)
+```
+
+After this code is created, the initial data process now owns the "hello" and "world" account objects. If these objects are not registered for deletion in subsequent versions of the code, they will be deleted when the initial data process executes. For example, assume the first piece of code executed and then the user executed this piece of code:
+
+```python
+from dynamic_initial_data.base import BaseInitialData
+
+class InitialData(BaseInitialData):
+    def update_initial_data(self):
+        world = Account.objects.get_or_create(name='world')
+        # register the accounts for deletion
+        self.register_for_deletion(world)
+```
+
+When this piece of code executes, the previous "hello" account would then be deleted since the initial data process no longer owns it. And don't worry, if it was already deleted by another process, the deletion will not throw an error.

{django-dynamic-initial-data-2.1.0 → django_dynamic_initial_data-3.0.0}/django_dynamic_initial_data.egg-info/SOURCES.txt

@@ -13,6 +13,7 @@ dynamic_initial_data/apps.py
 dynamic_initial_data/base.py
 dynamic_initial_data/exceptions.py
 dynamic_initial_data/models.py
+dynamic_initial_data/urls.py
 dynamic_initial_data/version.py
 dynamic_initial_data/management/__init__.py
 dynamic_initial_data/management/commands/__init__.py
@@ -30,4 +31,6 @@ dynamic_initial_data/tests/fake_app_2/__init__.py
 dynamic_initial_data/tests/fake_app_2/fixtures/__init__.py
 dynamic_initial_data/tests/fake_app_2/fixtures/initial_data.py
 dynamic_initial_data/tests/migrations/0001_initial.py
-dynamic_initial_data/tests/migrations/__init__.py
+dynamic_initial_data/tests/migrations/__init__.py
+requirements/requirements-testing.txt
+requirements/requirements.txt

django_dynamic_initial_data-3.0.0/django_dynamic_initial_data.egg-info/requires.txt

@@ -0,0 +1,2 @@
+Django>=5.2
+django-manager-utils>=4.0.0

django_dynamic_initial_data-3.0.0/dynamic_initial_data/__init__.py

@@ -0,0 +1,3 @@
+# flake8: noqa
+from .version import __version__
+

{django-dynamic-initial-data-2.1.0 → django_dynamic_initial_data-3.0.0}/dynamic_initial_data/apps.py

@@ -1,6 +1,6 @@
-from django.apps import AppConfig
-
-
-class DynamicInitialDataConfig(AppConfig):
-    name = 'dynamic_initial_data'
-    verbose_name = 'Django Dynamic Initial Data'
+from django.apps import AppConfig
+
+
+class DynamicInitialDataConfig(AppConfig):
+    name = 'dynamic_initial_data'
+    verbose_name = 'Django Dynamic Initial Data'