django-fast-treenode 2.1.0__py3-none-any.whl → 2.1.2__py3-none-any.whl

treenode/docs/cache.md

@@ -1,187 +0,0 @@
-## TreeNode Cache Management
-
-### First Generation
-
-The initial caching mechanism was inherited from the `django-treenode` package and was based on the simple use of Django's built-in cache. Each query result was stored in the cache, preventing repeated database queries and thereby improving performance.
-
-The advantage of this approach was its simplicity: it was easy to integrate and provided a speed boost without complex configurations. However, it also had significant drawbacks. Since the mechanism did not control the total memory usage, it quickly filled the cache with a vast number of small queries. This led to cache system overload, reduced efficiency, and slowed down other parts of the application that relied on the same cache. As a result, intensive operations with tree structures could cause memory management issues and impact cache system performance.
-
----
-
-### Second Generation
-
-In the current version, the caching mechanism has been enhanced with **memory usage limitation** for all models inheriting from `TreeNodeModel`. This was implemented as a **FIFO queue (First In, First Out)**, which automatically removes the oldest entries when the limit is exceeded.
-
-The choice of FIFO was driven by the package's universality. `django-fast-treenode` is designed to work in various scenarios, so it needed a strategy that efficiently handles evenly distributed queries. Even if queries are not evenly distributed in a particular project (e.g., some nodes are accessed more frequently than others), FIFO does not significantly reduce cache performance compared to the first-generation approach. However, it prevents uncontrolled memory growth, ensuring stable cache operation even under high request loads.
-
-
-#### Key Features
-
-**Global Cache Limit**: The setting `TREENODE_CACHE_LIMIT` defines the maximum cache size (in MB) for **all models** inheriting from `TreeNodeModel`. Default is **100MB** if not explicitly set in `settings.py`.
-
-**settings.py**
-``` python
-TREENODE_CACHE_LIMIT = 100
-```
-
-**Automatic Management**. In most cases, users don’t need to manually manage cache operations.All methods that somehow change the state of models reset the tree cache automatically.
-
-**Manual Cache Clearing**. If for some reason you need to reset the cache, you can do it in two ways:
-- **Clear cache for a single model**: Use `clear_cache()` at the model level:
-    ```python
-    MyTreeNodeModel.clear_cache()
-    ```
-- **Clear cache for all models**: Use the global `treenode_cache.clear()` method:
-    ```python
-    from treenode.cache import treenode_cache
-    treenode_cache.clear()
-    ```
-
----
-
-### Ceche API
-
-#### `@cached_method` Decorator
-
-The `@cached_method` decorator is available for caching method results in **class and instance methods** of models inheriting from `TreeNodeModel`. This decorator helps optimize performance by reducing redundant computations.
-
-```python
-from treenode.cache import cached_method
-from treenode.models import TreeNodeModel
-
-class Category(TreeNodeModel):
-    name = models.CharField(max_length=50)
-
-    @cached_method
-    def my_tree_method(self):
-        # Your code is here
-```
-
-In this example, `my_tree_method()` is cached.
-
-**Important:** The decorator should **only** be used with `TreeNodeModel` subclasses. Applying it to other classes will cause unexpected behavior.
-
-
-#### Accessing Cache via `treenode_cache`
-
-A global cache instance `treenode_cache` provides direct cache manipulation methods, allowing you to generate cache keys, store, retrieve, and invalidate cached values.
-
-Methods available in `treenode_cache`:
-
-#### generate_cache_key()
-Generates a unique cache key for caching method results. The key is based on model name, method name, object identifier, and method parameters.
-
-```python
-cache_key = treenode_cache.generate_cache_key(
-    label=Category._meta.label,  # Model label
-    func_name=self.<The method you are in>.__name__,
-    unique_id=42,   # This can be the object.pk. In a desperate situation, use id(self)
-    attr="some string value"
-)
-```
-This ensures that the cache key follows Django's conventions and remains unique.
-
-#### set()
-Stores a value in the cache.
-
-```python
-treenode_cache.set(cache_key, {'name': 'Root', 'id': 1})
-```
-This caches a dictionary object under the generated key.
-
-#### get()
-Retrieves a cached value by its cache key.
-
-```python
-cached_value = treenode_cache.get(cache_key)
-if cached_value is None:
-    cached_value = compute_expensive_query()
-    treenode_cache.set(cache_key, cached_value)
-```
-
-#### invalidate()
-Removes all cached entries for a **specific model**.
-
-```python
-treenode_cache.invalidate(Category._meta.label)
-```
-This clears all cache entries related to `Category` instances.
-
-#### clear()
-Clears **all** cached entries in the system.
-
-```python
-treenode_cache.clear()
-```
-This completely resets the cache, removing **all stored values**.
-
-Best Practices:
-- **Always use `generate_cache_key()`** instead of hardcoding cache keys to ensure consistency.
-- **Use `invalidate()` instead of `clear()`** when targeting a specific model’s cache.
-- **Apply `@cached_method` wisely**, ensuring it is used **only for** `TreeNodeModel`-based methods to avoid conflicts.
-- **Be mindful of cache size**, as excessive caching can lead to memory bloat.
-
-By leveraging these caching utilities, `django-fast-treenode` ensures efficient handling of hierarchical data while maintaining high performance.
-
----
-
-### Third Generation (Currently in Development)
-
-The next version of the caching mechanism introduces adaptability, a **split between "cold" and "hot" caches**, and enhanced eviction strategies. Key improvements include:
-
-#### 1. Two-Tier Caching System
-
-The cache is now divided into two queues:
-
-- **FIFO (70%-80%)** – for new and infrequently accessed data.
-- **LRU (20%-30%)** – for frequently accessed objects (Least Recently Used).
-
-How it works:
-- If tree queries are evenly distributed, the cache behaves like a standard FIFO.
-- If certain nodes receive frequent queries, those records automatically move to LRU, reducing database load.
-
-#### 2. Moving Data Between FIFO and LRU
-
-Each new entry initially goes into **FIFO**. If accessed **more than N times**, it moves to **LRU**, where it remains longer.
-
-**How N is determined:**
-- A threshold is set based on **mathematical statistics**: N = 1 / sqrt(2).
-- An absolute threshold limit is added.
-
-**LRU Behavior:**
-- When accessed, a record moves to the top of the list.
-- New records are also placed at the top.
-- If LRU reaches capacity, **the evicted record returns to FIFO** instead of being deleted.
-
-#### 3. Cache Invalidation
-
-When data is modified or deleted, the cache **automatically resets** to prevent outdated information. This ensures that modified tree structures do not retain stale data in the cache.
-
-#### 4. Dynamic Time Threshold (DTT)
-
-To automatically clear outdated records, an **adaptive mechanism** is used. Instead of a static TTL, the **DTT parameter** is dynamically calculated based on **Poisson distribution**.
-
-How DTT is calculated:
-1. Compute the **average interval between queries (T)**: ``` T = (1/N) * Σ (t_i - t_(i-1)), i=1...N```
-2. Store **averaged value** `ΣΔt / N`
-3. Set **DTT = 3T**, which removes **95% of infrequent queries**.
-
-**Why this is better than a fixed TTL:**
-- If queries are rare → DTT **increases**, preventing premature deletions.
-- If queries are frequent → DTT **decreases**, accelerating cache clearing.
-
-All calculations happen **automatically**, without manual configuration.
-
-Additionally, this mechanism will support synchronization in multiprocess environments (WSGI, Gunicorn, Uvicorn).
-
----
-
-### Fourth Generation (Planned)
-
-The next generation of caching will include:
-
-- **Middleware for caching nodes**, considering nested objects.
-- **"Smart" prediction** of peak and dynamics of loads.
-- **Asynchronous operations** support, ensuring efficient caching and retrieval in non-blocking environments.
-
-Future versions will continue improving this mechanism, making it **even more efficient and predictable** when working with large tree structures.

treenode/docs/import_export.md

@@ -1,35 +0,0 @@
-## Import&Export Functionality
-### Overview
-
-TreeNode v2.0 includes **built-in export and import features** for easier data migration. Supported Formats: `csv`, `json`, `xlsx`, `yaml`, `tsv`. The system supports importing and exporting data for any models, allowing users to efficiently manage and update data while preserving its structure and relationships.
-
-### Installation for Import/Export Features
-By default, import/export functionality is **not included** to keep the package lightweight. If you need these features, install the package with:
-```bash
-pip install django-fast-treenode[import_export]
-```
-
-Once installed, **import/export buttons will appear** in the Django admin interface.
-
-### Data Processing Logic
-When importing data into the system, **three key fields** must be present:
-- **`id`** – the unique identifier of the record.
-- **`tn_parent`** – the identifier of the parent node.
-- **`tn_priority`** – the ordinal number of the node among its parent's children.
-
-These fields ensure the correct construction of the hierarchical data structure.
-
-Important:
-- If a record with the same `id` **already exists** in the database, its data **will be updated** with the imported values.
-- If no record with the given `id` **is found**, a **new record will be created** with the specified parameters.
-
-This import mechanism is designed to allow users to:
-- **Export data**, edit it (e.g., in a CSV, Excel, or JSON file).
-- **Upload the modified file** without disrupting the model structure.
-- **Update only the changed data**, keeping relationships with other models intact (e.g., without altering primary and foreign key values).
-
-This approach provides **flexible data management**, enabling users to safely apply modifications without manually updating each record in the system.
-
-### Important Considerations
-
-Exporting objects with M2M fields may lead to serialization issues. Some formats (e.g., CSV) do not natively support many-to-many relationships. If you encounter errors, consider exporting data in `json` or `yaml` format, which better handle nested structures.

treenode/docs/index.md

@@ -1,30 +0,0 @@
-# Django Fast TreeNode
-
-Welcome to the **django-fast-treenode** documentation!
-
-## Key Features
-**django-fast-treenode** is a high-performance solution for managing tree structures in Django.
-
-- **Fast processing** even with deep trees  
-- **Intuitive API** for seamless integration  
-- **Django Admin support** for easy management  
-- **Optimized caching** for enhanced performance  
-
-## Contents
-- [About the Project](about.md)
-- [Installation, Configuration, and Fine-Tuning](installation.md)
-- [Model Inheritance and Extensions](models.md)
-- [Working with Admin Classes](admin.md)
-- [API Reference](api.md)
-- [Import & Export](import_export.md)
-- [Caching and Cache Management](cache.md)
-- [Migration and Upgrade Guide](migration.md)
-- [Roadmap](roadmap.md)
-
-## Links
-- [Issues](https://github.com/TimurKady/django-fast-treenode/issues)
-- [Pull Requests](https://github.com/TimurKady/django-fast-treenode/pulls)
-- [Discussions](https://github.com/TimurKady/django-fast-treenode/discussions)
-
-## License
-Released under the [MIT License](https://github.com/TimurKady/django-fast-treenode/blob/main/LICENSE).

treenode/docs/installation.md

@@ -1,74 +0,0 @@
-## Configuration Guide
-
-### Installation
-
-#### First-Time Installation
-If you are installing `django-fast-treenode` for the first time, the process is straightforward. Simply install the package via `pip`:
-
-```sh
-pip install django-fast-treenode
-```
-
-Once installed, add `'treenode'` to your `INSTALLED_APPS` in `settings.py`:
-##### settings.py
-```python
-INSTALLED_APPS = [
-    ...
-    'treenode',
-]
-```
-
-Then, apply migrations:
-
-```sh
-python manage.py migrate
-```
-
-#### Upgrading or Migrating from `django-treenode`
-If you are upgrading to a new version of `django-fast-treenode` or switching from `django-treenode`, it is essential to run migrations to ensure data consistency:
-
-```sh
-pip install --upgrade django-fast-treenode
-python manage.py migrate
-```
-
-#### Migrating from Other Packages
-If you are migrating from other tree management solutions, additional steps may be required. Please refer to the [Migration and Upgrade Guide](migration.md) for detailed instructions.
-
----
-
-### Configuration
-
-#### Cache Setup
-To optimize performance, `django-fast-treenode` uses caching for tree structure operations. You can define a **dedicated cache backend** for the package by adding a `"treenode"` entry to `settings.CACHES`. If no dedicated cache is provided, the default Django cache will be used.
-
-##### settings.py
-```python
-CACHES = {
-    "default": {
-        "BACKEND": "django.core.cache.backends.filebased.FileBasedCache",
-        "LOCATION": "...",
-    },
-    "treenode": {
-        "BACKEND": "django.core.cache.backends.locmem.LocMemCache",
-        "KEY_PREFIX": "",   # This is important!
-        "VERSION":  None,    # This is important!
-    },
-}
-```
-**Important Notes:**
-- You can use **any cache backend**, including Django’s built-in options or external solutions like **Redis** or **Memcached** .
-- **`KEY_PREFIX` must be an empty string (`""`)**, and **`VERSION` must be `None`**, otherwise cache inconsistencies may occur.
-
----
-
-#### Cache Size Allocation
-By default, the cache stores all tree-related data for models inheriting from `TreeNodeModel`. You can control the cache size using `TREENODE_CACHE_LIMIT` in **megabytes**.
-
-##### settings.py
-```python
-TREENODE_CACHE_LIMIT = 100
-```
-This setting determines the memory allocation for caching **all instances** of tree models.
-
-For more details on how caching works and how to fine-tune its behavior, refer to the [Caching and Cache Management](cache.md)  Guide.

treenode/docs/migration.md

@@ -1,145 +0,0 @@
-## Migrations Guide
-### Migration from _django-treenode_ packege
-The migration process from `django-treenode` is fully automated. No manual steps are required. Upon upgrading, the necessary data structures will be checked and updated automatically.
-Run the following commands in the terminal:
-
-```bash
-pip install django-fast-treenode
-python manage.py makemigrations
-python manage.py migrate
-python manage.py runserver
-```
-It's unlikely that you'll need or want this, but in exceptional cases you can call the whole tree update code `cls.update_tree()` manually.
-
----
-
-### Update _django-fast-treenode_ version 2.1 and less
-The sequence of actions when migrating from previous versions of `django-fast-treenode` is similar to upgrading models of the `django-treenode` package.
-Run the following commands in the terminal:
-
-```bash
-pip install --upgrade django-fast-treenode
-python manage.py makemigrations
-python manage.py migrate
-python manage.py runserver
-```
-Now your models are updated and running even faster than before.
-
----
-
-### Migration from _django-mptt_ or _django-treebeard_ packege
-Migration from other packages is not as seamless as with `django-treebeard`, which is probably understandable. However, `django-fast-treenode` has been specially tweaked so that such migration requires minimal effort, including minimal changes to your project code.
-Below is a guide on how to migrate to `django-fast-treenode` from other packages using a project using `django-treebeard` as an example. Migration from other packages will involve similar steps.
-
-#### Step 1: Export existing data
-Launch the Python console:
-
-```bash
-python manage.py shell
-```
-
-Run the following code to export the tree structure:
-```python
-from yourapp.models import Category
-import json
-
-data = []
-
-def export_tree(node):
-    children = node.get_children()
-    return {
-        "id": node.id,
-        "tn_parent": node.get_parent().id if node.get_parent() else None,
-        "name": node.name,
-        # Continue the list by inserting the required model fields
-        # Do not export the `children` field
-    }
-
-roots = Category.objects.filter(depth=1)  # treebeard root nodes
-for root in roots:
-    data.append(export_tree(root))
-
-with open("tree_data.json", "w") as f:
-    json.dump(data, f, indent=4)
-```
-
-This code exports your structure to `tree_data.json` file. JSON preserves the id → tn_parent relationship, but without children.
-
-Now clear the table:
-```python
-Category.objects.all().delete()
-```
-Remove `django-treebeard` if it is installed:
-```bash
-pip uninstall django-treebeard
-```
-Install `django-fast-treenode`:
-```bash
-pip install django-fast-treenode
-```
-
-Before you start the migration, it is important to make sure **you have a backup of your database**, as the tree storage structure will change.
-
-#### Step 2: Preparing for Migration
-If you have a model in your project that uses `treebeard`, it probably looks like this:
-```python
-from treebeard.mp_tree import MP_Node
-
-class Category(MP_Node):
-    name = models.CharField(max_length=255)
-```
-Now we need to adapt it for `django-fast-treenode`. Change the model to use `TreeNodeModel` instead of `MP_Node`:
-```python
-from treenode.models import TreeNodeModel
-
-class Category(TreeNodeModel):
-    name = models.CharField(max_length=255)
-
-    treenode_display_field = "name"
-    treenode_sort_field = "None"
-```
-Be sure to add `treenode_display_field` as `django-fast-treenode` uses it to display nodes in the admin panel. 
-
-The `treenode_sort_field` attribute specifies the tree sorting order. The default value of this field is `None`. It will sort by the internal field `tn_priority`.
-
-The `tn_priority` value will be generated automatically if not specified during import. It will either be set as nodes are inserted into the tree (in the order in which the nodes will appear in the imported data), or after they are inserted, depending on the results of sorting by the field specified in the `treenode_sort_field` attribute.
-
-> Note: sorting functions are available for `django-tree-node` version 2.3 and higher.
-
-#### Step 3: Update the code
-The `django-fast-treenode` package contains the full set of methods you are used to. But the methods for working with the tree are slightly different. For example:
-
-|**django-treebeard** | **django-fast-treenode** |**Features of use**|
-|---------------------|----------------------|----------------------|
-| The `pos` parameter in `add_sibling()` and `move()` methods |  The parameter `pos` has the name `position` | • The `position` parameter in `django-fast-treenode` always consists of two parts separated by `-`: the first part determines the insertion method (_first, left, right, last, sorted_), the second — the placement type (_child, sibling_). <br> • Instead of a string format, you can also pass position as an integer indicating the exact position of the node in the list.|
-|`get_siblings()`, `get_ancestors()` end ect. | Similar methods have parameters `include_self` and `depth` |• The `include_self` parameter specifies whether to include the node itself in the selection. <br> • The  `depth` parameter specifies the depth of the search. |
-|`move(target, pos)` metiod| The method `move()` has the name `move_to(target, position)` | - |
-
-As you can see, unlike treebeard, django-fast-treenode provides more features, allowing you to use familiar methods more flexibly.
-
-For more details, refer to the `django-fast-treenode` documentation and update your code accordingly
-
-
-#### Step 4: Create Migrations
-After changing the model, new migrations need to be created and applied.
-
-```bash
-python manage.py makemigrations
-python manage.py migrate
-```
-
-After a successful migration, you can remove references to `django-treebeard` in `requirements.txt` and `INSTALLED_APPS` if they were there.
-
-#### Step 5:  Data Import
-Now start the server.
-   ```bash
-   python manage.py runserver
-   ```
-
-Go to Django Admin and import data into your model from the previously saved file. `django-fast-treenode` will do everything automatically. Check if the tree structure is displayed correctly. 
-
-Moreover, the import will preserve the `id` of all nodes, which will ensure that the values of the keys referencing your model are unchanged.
-
----
-
-Now your project has completely migrated from `django-treebeard` to `django-fast-treenode`. Your tree is more performant and easier to use, and your code is cleaner and more flexible.

treenode/docs/models.md

@@ -1,128 +0,0 @@
-## Model Inheritance and Extensions
-
-### Model Inheritance
-
-To define a model that supports tree structures, simply inherit from `TreeNodeModel`. Below is an example of a basic category model:
-
-##### models.py
-
-```python
-from django.db import models
-from treenode.models import TreeNodeModel
-
-class Category(TreeNodeModel):
-
-    treenode_display_field = "name"  # Defines the field used for display in the admin panel
-
-    name = models.CharField(max_length=50)
-
-    class Meta(TreeNodeModel.Meta):  # Ensure TreeNodeModel's indexing settings are preserved
-        verbose_name = "Category"
-        verbose_name_plural = "Categories"
-```
-
-Key Considerations:
-- `treenode_display_field`  
-This attribute defines which field will be used to display the tree structure in the Django admin panel. If it is not set, nodes will be named generically as `"Node <id>"`, where `<id>` is the primary key of the record.
-- Inheriting model Meta class from `TreeNodeModel.Meta`
-It is **essential** to inherit the `Meta` class from `TreeNodeModel.Meta`. Failure to do so may impact database performance and query efficiency.
-
-With this setup, your model will seamlessly integrate into Django, supporting hierarchical relationships while maintaining optimized indexing and efficient querying.
-
-
-### Model Extending
-
-When extending a model based on `TreeNodeModel`, you have full flexibility to add custom fields and methods. However, to ensure compatibility and maintainability, follow these best practices.
-
-#### General Guidelines
-You are free to add new fields and methods. The basic model does not impose any restrictions on the expansion of functionality. However, it is strongly recommended to adhere to the principles and standards of the object-oriented approach.
-**Avoid direct access to model fields** when modifying tree-related data.  
-     Fields with the `tn_` prefix **may be renamed in future versions** (this is already planned). Instead of assigning values directly, use **accessor and mutator methods**:  
-```python
-# ❌ Avoid direct assignment
-node.tn_parent = other_node
-
-# ✅ Use the provided method
-node.set_parent(other_node)
-```
-**Hardcoding field names may lead to compatibility issues in future updates.** Always use methods provided by the package when working with tree structures.
-
-#### Extending Indexing
-
-If your model requires additional indexing, **do not override the indexing settings of `TreeNodeModel.Meta`**. Instead, extend them properly using Django’s index definitions.
-
-If you want to add an index to a new or existing field (e.g., `"name"`), do it as follows:
-
-```python
-from django.db import models
-from treenode.models import TreeNodeModel
-
-class Category(TreeNodeModel):
-
-    treenode_display_field = "name"
-
-    name = models.CharField(max_length=50, db_index=True)  # Adding an index to "name"
-
-    class Meta(TreeNodeModel.Meta):  # Preserve indexing settings from TreeNodeModel
-        indexes = TreeNodeModel.Meta.indexes + [
-            models.Index(fields=["name"]),
-        ]
-        verbose_name = "Category"
-        verbose_name_plural = "Categories"
-```
-
-By following these principles, your extended models will remain stable, maintainable, and compatible with future versions of `django-fast-treenode`.
-
-### Customize Managers
-
-When defining custom model managers for `TreeNodeModel`, it is **essential** to extend `TreeNodeModelManager` rather than modifying internal components like `ClosureQuerySet`, `ClosureModelManager`, or `TreeNodeQuerySet`. Direct manipulation of these lower-level structures **can lead to data corruption** and is not guaranteed to remain stable in future versions.
-
-#### Always Extend TreeNodeModelManager
-To ensure stability and maintain tree integrity, always **extend** `TreeNodeModelManager`. Never directly interact with internal tree structures like the Closure Table or adjacency list.
-
-Example: Safe Custom Manager:
-```python
-from treenode.managers import TreeNodeModelManager
-
-class CustomTreeNodeManager(TreeNodeModelManager):
-    def active(self):
-        """Return only active nodes."""
-        return self.get_queryset().filter(is_active=True)
-```
-**Correct**: This approach preserves all core tree operations while adding custom behavior.
-
-#### Avoid Direct Parent-Child Modifications
-Modifying relationships improperly can break the tree structure. Use built-in methods instead:
-
-Safe Parent Update:
-```python
-node.set_parent(new_parent)  # ✅ Safe
-node.tn_parent = new_parent  # ❌ Unsafe (bypasses tree updates)
-```
-
-#### **3. Use `bulk_create` and `bulk_update` Carefully**
-Since tree structures require synchronization between adjacency and closure models, **always use transactions**:
-
-Safe Bulk Create Example:
-
-```python
-from django.db import transaction
-
-class CustomTreeNodeManager(TreeNodeModelManager):
-    @transaction.atomic
-    def bulk_create(self, objs, batch_size=1000):
-        """Ensures proper insertion of nodes without breaking the tree."""
-        objs = super().bulk_create(objs, batch_size=batch_size)
-        return objs
-```
-**Important**: Do not directly insert nodes without using `bulk_create` from `TreeNodeModelManager`.
-
-#### Custom Queries
-Use `get_queryset()` Instead of QuerySet Overrides. If custom queries are needed, **override `get_queryset()`** in your manager instead of modifying internal querysets:
-```python
-class CustomTreeNodeManager(TreeNodeModelManager):
-    def get_queryset(self):
-        return super().get_queryset().filter(is_active=True)
-```
-
-By following these principles, you ensure your custom managers remain **future-proof**, **safe**, and **maintainable** without the risk of breaking tree integrity.

treenode/docs/roadmap.md

@@ -1,45 +0,0 @@
-## Roadmap
-The latest version provides optimized database operations, an improved caching mechanism, and enhanced integration capabilities, making it a **robust and efficient choice** for handling tree structures.
-
-But the **django-fast-treenode** package will continue to evolve from its original concept—combining the benefits of the **Adjacency List** and **Closure Table** models—into a high-performance solution for managing and visualizing hierarchical data in Django projects. The focus is on **speed, usability, and flexibility**.
-
-In future versions, I plan to implement:
-
-### **Version 2.1 – Compatibility and Optimization**
-Reducing dependencies and simplifying migration from other libraries.
-- **Expanding functionality** to simplify migration from other tree packages.
-- Introducing node **filtering and search with AJAX**.
-- **Optimizing query performance** by reducing query complexity and improving indexing strategies.
-- **Reducing database load** from the `TreeNodeAdmin` when working with large trees.
-- Removing `numpy` in favor of lighter alternatives.
-
-### **Version 2.2 – Caching Improvements**
-Speeding up tree operations and reducing database load.
-- **Implementing a more efficient caching algorithm** to optimize performance and reduce recomputation.
-- **Refining cache expiration strategies** for better memory management.
-
-### **Version 2.3 – Performance Enhancements**
-- **Reducing query overhead** and optimizing bulk operations for large datasets.
-- **Django REST Framework (DRF)**: Adding initial integration for efficient tree-based API handling.
-- **Serialization**: Developing lightweight tree serialization for API-first projects.
-- **Enhancing node filtering and search** with AJAX-driven interfaces.
-
-### **Version 2.4 – Drag-and-Drop and Admin UI Improvements**
-- **Drag-and-Drop**: Adding drag-and-drop support for node sorting in Django admin.
-- **Advanced Sorting**: Adding multiple sorting strategies for tree nodes, including manual ordering and hierarchical priority rules.
-- **Admin Panel Enhancements**: Expanding the functionality of the Django admin interface for managing hierarchical data more efficiently.
-
-### **Version 3.0 – Asynchronous operations and Fourth-Generation Cache Management System**
-- **Asynchronous operations** support, ensuring efficient working and data processing in non-blocking environments.
-- **Shifting from caching computed results to directly caching tree nodes**, reducing recomputation overhead and improving cache efficiency.
-- **Reworking Adjacency List and Closure Table managers** for a new caching system.
-- **Enhancing cache consistency** across multiple processes (WSGI, Gunicorn, Uvicorn) with a global synchronization mechanism.
-
-### **Version 4.0 – Moving Beyond Django ORM**
-Enabling tree structures to function without a strict dependency on Django ORM while maintaining compatibility.
-- **Introducing support for various storage backends**, allowing greater flexibility.
-- **Adding compatibility with Redis for in-memory tree storage** and JSON-based trees for lightweight embedded storage.
-- **Expanding usage in API-first projects**, enabling tree structures to work independently from Django models.
-
-Stay tuned for updates!
-Your wishes, objections, and comments are welcome.