Wq.db

Latest version: v2.1.0

Safety actively analyzes 688758 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 1 of 8

2.1.0

**wq.db 2.1.0** is the first stable release of the wq.db 2.1 series! Be sure to check out the [latest documentation](https://wq.io/) and the [release notes for wq 2.1](https://github.com/wq/wq/releases/v2.1.0) when upgrading.

All changes by sheppard.

* Built-in Mapbox Vector Tile (MVT) server for all geometry models registered with [wq.db's router](https://wq.io/wq.db/router) (de0d9e8).
* This feature currently only works when using PostGIS as a backend.
* If enabled, a `tiles` URL path will be added to the [config JSON](https://wq.io/config) to tell [wq/map-gl](https://wq.io/wq/map-gl) where to load the geometries from.
* Option to defer loading GeoJSON geometries through REST API (171003f), particularly if they are going to be loaded via MVT instead.
* Confirm support for Python 3.12 and Django 5.0 (fcdfcf9, fbe345e)

2.0.0

**wq.db 2.0.0** is the first stable release of the wq.db 2.0 series! Be sure to check out the [latest documentation](https://wq.io/) and the [release notes for wq 2.0](https://github.com/wq/wq/releases/v2.0.0) when upgrading.

This major release simplifies and removes some functionality in order to focus on wq.db's core functionality. See [wq.db 1.3.2](https://github.com/wq/wq.db/releases/v1.3.2) if you would like a Django 4.1-compatible version of wq.db that maintains the other features of wq.db 1.3.

Changes since wq.db 2.0 alpha 2

None.

2.0.0a2

**wq.db 2.0 alpha 2** is the second preview of the next version of wq.db, as part of the [wq 2.0 alpha 2](https://github.com/wq/wq/releases/v2.0.0a2) release.

All changes by sheppard.

* Don't crash when `ModelSerializer` is used without a router (5cf83a3)

2.0.0a1

**wq.db 2.0 alpha** is a preview of the next version of wq.db, as part of the [wq 2.0 alpha](https://github.com/wq/wq/releases/v2.0.0a0) release. This major release includes a number of breaking changes, including the complete removal of the `wq.db.patterns` module in favor of a simpler API for nested models.

Changes by sheppard except where noted.

New APIs

`register` decorator

wq.db.rest now provides a top-level `register` decorator that directly mimics the Django admin's `register`. It is useful for creating and directly registering a custom Serializer classes:
python
from wq.db import rest
from .models import MyModel

rest.register(MyModel, url="customurl")
class MyCustomSerializer(rest.ModelSerializer)
class Meta:
wq_field_config = {...}


In addition, `rest.router.register()` now accepts a model as the first argument, making it more like `admin.site.register()`. If the first argument is a model it will call `rest.router.register_model()`, otherwise it will defer to Django REST Framework's `DefaultRouter.register()` as before.

These changes were introduced in f93c4d8.

Streamlined Registration for Nested Models

The `wq.db.patterns` module previously provided a number of extended serializers to facilitate registering models as "attachments" under a primary parent model. This API worked well enough but was cumbersome to use. The extended serializers (and the `wq.db.patterns` module itself) have been removed in favor of a simpler API that is built into the default [ModelSerializer](https://wq.io/wq.db/serializers).

python
from wq.db import rest
from .models import ParentModel, ChildModel

rest.router.register(
ParentModel,
nested_arrays=[ChildModel],
fields="__all__",
)


The `nested_arrays` argument will automatically create a nested serializer attribute on the serializer for ParentModel.

If you need to customize the nested serializer, you can do so in one of three ways:

* Register the child model with the router as a separate top-level API with an explicit serializer. wq.app will automatically handle translating child records between ORM models and forms for the parent and child APIs.
* Register just the child serializer with `rest.router.register_serializer(ChildModel, ChildSerializer)`
* Explicilty define a `ChildSeriizer` attribute on a custom `ParentSerializer`. This is more or less how it was done before, but now both serializers can just extend `wq.db.rest.ModelSerializer` rather than the separated serializers from `wq.db.patterns`.

python
from wq.db import rest
from .models import ParentModel, ChildModel

class ChildSerializer(rest.ModelSerializer):
class Meta:
model = ChildModel

rest.register(ParentModel)
class ParentSerializer(rest.ModelSerializer):
children = ChildSerializer(
many=True,
wq_config={
"initial": {
"type_field": "type",
},
},
)


This change was introduced in f93c4d8 and by updating wq.db's default `ModelSerializer` to extend two base classes:
* `NaturalKeyModelSerializer` from [django-natural-keys](https://github.com/wq/django-natural-keys)
* `WritableNestedModelSerializer` from [drf-writable-nested](https://github.com/beda-software/drf-writable-nested)

Enhancements & Fixes
* Compatibilty with Django REST Framework 3.14 (84 by ydf)
* Simplify user-specific config JSON to only include permissions (wq/wq54)
* Improve foreign key support (02e889e, 9155e5b)
* Report related_name in the wq config object for use by the client ORM
* Detect DRF's `SlugRelatedField` in addition to wq.db's `LookupRelatedField` when mapping foreign key columns.
* Reduce extraneous database queries
* Remove `ContentType` proxy class in favor of additional router methods (9155e5b)
* Remove automatic label generation for foreign keys (9155e5b)
* Leverage `PKOnlyObject` optimization if the ForeignKey's `to_field` is the same as the slug value. (9155e5b)
* If `cache="filter"` or `cache="autoupdate"` is specified without an explicit `cache_filter`, return an empty response instead of the entire table (8cc1e0c)
* Improve fieldset configuration and JSON parsing (5da66b1, 4e97e1b, b5c5e7d, aab0284)
* Don't create URL routes for configurations registered with `external=True` (7898de4)
* Clean up code style and project layout (969798b, 9499bb6)

Removed Functionality

Several modules and functions have been removed. Most of these only remained for backwards compatibility with projects built with wq 1.2 and earlier versions.

* Removed `ModelSerializer.add_lookups()` and other support for Mustache templates (7556674, 02e889e)
* Removed `wq.db.rest.context_processors`
* Removed `wq.db.rest.auth.context_processors`
* Removed `wq.db.default_settings` (02e889e).
* Take a look at [wq django template 2.0 alpha](https://github.com/wq/wq-django-template/releases/v2.0.0a0) to see what are settings are still relevant to wq-powered projects.
* Removed `wq.db.patterns.identify` and the rest of `wq.db.patterns` (02e889e, f93c4d8)
* Use the streamlined API above instead.
* Removed compatibility with Django 1.x-style `include()` (02e889e)
* If for some reason you are still calling `path('', include(rest.router.urls))`, change this to just `path('', rest.router.urls)`.
* Removed `wq.db.rest.model_tools`, `wq.db.rest.models.ContentType`, and `wq.db.rest.migrations` (9155e5b)
* Removed automatic `[fkname]_label` serializer fields (9155e5b).
* Use `fkname_label = serializers.ReadOnlyField(source='fkname.__str__')` if you were relying on this functionality.

1.3.2

**wq.db 1.3.2** brings Django 4.1 compatibility to the wq.db 1.3 branch. Thanks to tomaszn for contributing the necessary changes (85).

> Note that wq.db 1.3's EAV support does not work with Django 4.1 - if you need this, consider updating to wq 2.0 which handles all EAV logic on the client.

1.3.1

This maintenance release pins Django REST Framework to 3.13 or earlier to avoid a compatibility issue (wq/wq61). Support for for DRF 3.14 is available in the main branch (via 84), which will be released in wq.db 2.0.

Page 1 of 8

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.