Skip to main content
100%

DRF, Getters Setters, PolymorphicModel

✓ Published0🌍 Public
Aandybak
Last edited Apr 10, 2014
Created on Apr 10, 2014

This example shows a Django REST Framework serializer that exposes a computed `driver` property on a polymorphic model, delegating to either the delivery or collection driver based on the model’s type. The `models.py` file defines `MyModel` with a `PolymorphicModel` base, using `@property` and `@setter` to route reads and writes to the correct foreign-key field. The `serializers.py` class `MyModelSerializer` subclasses `ModelSerializer` and declares `driver = UserSerializer()` to output the nested user object. The code demonstrates how to unify two underlying fields into a single API field without custom serializer logic.

AI-generated description

Similar vizzes

Loading thumbnail…

Gist 8479609

This example shows a Django REST Framework serializer that exposes booking data alongside a dynamic list of salesperson options. The `BookingSerializer` model serializer outputs fields for booking ID, booking number, current salesperson, and a custom `sales_people_options` field. The `UserOptionsField` uses the `field_to_native` method to query all users and return their IDs and usernames, providing a dropdown-style selection list in the API response. It relies on Django’s ORM and the `serializers.ModelSerializer` and `serializers.Field` classes from Django REST Framework.

Aandybak
52% match
Loading thumbnail…

Gist 9295126fbe6657c96185

This visualization shows the relationship between Django model fields and their cached property aliases in a database schema. It uses the Django ORM’s `models.DateTimeField` and `models.ForeignKey` to define the base order row’s timestamp and two related inventory item references, while `@cached_property` methods expose either the confirmed stock item or the unconfirmed item model. The code demonstrates how `is_confirmed` switches between the two foreign keys, returning `None` for the unused one. The example relies on Django’s model inheritance and the `cached_property` decorator to manage lazy-loaded relationships, illustrating a pattern where alternate field names are hidden behind a single logical accessor.

Aandybak
50% match
Loading thumbnail…

Gist 6138a5680dbc66f83c6d

This example demonstrates a Django admin customization module that renders reverse foreign-key and one-to-one relationships as inline formsets, replacing the default select-box interface. The code uses Django’s `ModelAdmin`, `InlineModelAdmin`, and `BaseModelFormSet` to create `ReverseInlineFormSet`, which limits the formset to a single existing object or a single empty form, and supports tabular or stacked layouts via `inline_type`. It also references Django’s `csrf_protect_m`, `flatten_fieldsets`, and formset validation utilities, with the source being a gist by andybak adapted for Django 1.6.

Aandybak
50% match
Loading thumbnail…

Gist 80e860673485f5ffdb08

This example demonstrates a Django admin enhancement called ReverseModelAdmin, which improves the management of OneToOneField and ForeignKey relationships by rendering them as reverse inlines instead of standard select boxes. The code defines a custom formset, ReverseInlineFormSet, and a factory function to create inline formsets that display related models embedded within the parent admin page. It uses Django’s admin internals, including InlineModelAdmin, ModelForm, and modelformset_factory, to support tabular or stacked layouts for the related data.

Aandybak
48% match
Loading thumbnail…

Creating Intercooler-friendly custom endpoints in a Django Rest Framework viewset.

This example shows a Django Rest Framework viewset that returns plain HTML responses for Intercooler AJAX requests while using normal content negotiation for other clients. A custom `IntercoolerContentNegotiation` class overrides `select_renderer` to check for an `ic-request` parameter in the request data, switching to `StaticHTMLRenderer` and `text/html` when present. The viewset defines two custom actions, `do_something` and `do_something_else`, each returning a simple `Response` object with a string. The code demonstrates how to integrate Intercooler’s request pattern into DRF’s renderer selection mechanism without altering the view logic.

Aandybak
48% match
Loading thumbnail…

Gist 03e850f4a387ea3d2a16648508705d10

This example shows how to test Django model relationships using pytest with randomized data generation. It defines two models, ModelA and ModelB, linked by a OneToOneField, and then uses the pytest_quickcheck library’s Generator classes (modelA and modelB) to create random instances with generated string fields. The test verifies that a repository’s `get_members` method returns the same list of saved models, using `pytest.mark.randomize` with `list_of` to generate up to 20 model instances, and fixtures (save_models) to persist them to the database before asserting equality.

CCheckroth
47% match
Loading thumbnail…

Gist 24eed51a3fba9e14760d

This example visualizes a Django data model’s query-set filtering logic as a directed graph, showing how `ItemModelQuerySet` methods such as `consumable`, `tracked`, and `hireable` branch from the base `ItemModelManager`. The graph nodes represent query-set operations and their type-based filter relationships, with edges indicating method chaining. It uses the `PassThroughManager` API to expose custom queryset methods, while the rendering approach likely relies on a JavaScript library like `d3.forceSimulation` for node layout, though the code itself focuses on the Python-side model definitions. The data source is the hardcoded queryset class structure from the gist.

Aandybak
47% match
Loading thumbnail…

Gist 203774

This example demonstrates a data model involving three linked DataMapper resources—Foo, Bar, and Baz—with bidirectional associations and a nullable belongs-to relationship for tracking a current bar. It shows how to define database schema properties, Sweatshop fixtures for generating sample records, and an in-memory SQLite setup followed by auto-migration. The code creates a Foo with its bars and bazs, then updates the Foo’s current_bar reference to its first bar, illustrating persistence and association handling through DataMapper’s API and the `dm-sweatshop` fixture generator.

XXXX
46% match