HTML color code field
A CharField (Model) that checks that the value is a valid HTML color code (Hex triplet) like #FFEE00.
- model
- db
- color
- hexcode
Snippet List
ActiveManager: filter objects depending on publication and/or expiration dates
This manager is intended for use with models with publication and/or expiration dates. Objects will be retrieved only if their publication and/or expiration dates are within the current date. Use is very simple: class ExampleModel(models.Model): publish_date = models.DateTimeField() expire_date = models.DateTimeField(blank=True, null=True) objects = models.Manager() actives = ActiveManager(from_date='publish_date', to_date='expire_date') ExampleModel.actives.all() # retrieve active objects according to the current date The manager works correctly with nullable date fields. A null publication date means "*always published (until expiration date)*" and a null expiration date means "*never expires*". Most models should define the `objects` manager as the default manager, because otherwise out of date objects won't appear in the admin app.
- model
- manager
- active
- publication
- expiration
- date-filter
OwnerField
This is a little helper for associating an owner to a newly created object, in this case making the assumption that the current user is always the owner. It removes the necessity of adding a custom save hook to your model. get_current_user comes from this middleware trick to cache the current user: http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser
- model
- user
- field
- owner
- ownerfield
CompressedTextField for Django 1.4+
This snippet *updates* http://www.djangosnippets.org/snippets/383/ and http://www.djangosnippets.org/snippets/1495/ for Django 1.4+, and adds support for sqlite3 and south. Original snippet text: A CompressedTextField to transparently save data gzipped in the database and uncompress at retrieval.
- text
- model
- field
- compressed
- gzip
- south
Binding signals to abstract models
Intro ----- I found a question on SO for which Justin Lilly's answer was correct but not as thorough as I'd like, so I ended up working on a simple snippet that shows how to bind signals at runtime, which is nifty when you want to bind signals to an abstract class. Bonus: simple cache invalidation! Question -------- [How do I use Django signals with an abstract model?](http://stackoverflow.com/questions/2692551/how-do-i-use-django-signals-with-an-abstract-model) I have an abstract model that keeps an on-disk cache. When I delete the model, I need it to delete the cache. I want this to happen for every derived model as well. If I connect the signal specifying the abstract model, this does not propagate to the derived models: pre_delete.connect(clear_cache, sender=MyAbstractModel, weak=False) If I try to connect the signal in an init, where I can get the derived class name, it works, but I'm afraid it will attempt to clear the cache as many times as I've initialized a derived model, not just once. Where should I connect the signal? Answer ------ I've created a custom manager that binds a post_save signal to every child of a class, be it abstract or not. This is a one-off, poorly tested code, so beware! It works so far, though. In this example, we allow an abstract model to define CachedModelManager as a manager, which then extends basic caching functionality to the model and its children. It allows you to define a list of volatile keys that should be deleted upon every save (hence the post_save signal) and adds a couple of helper functions to generate cache keys, as well as retrieving, setting and deleting keys. This of course assumes you have a cache backend setup and working properly.
- managers
- models
- cache
- model
- manager
- signals
- abstract
- signal
- contribute_to_class
Automatic CRUD urls from your models...
Just extends your models from this One... is abstract so, it will not generate a table. Now, in your urls.py do this: from django.conf.urls.defaults import * from animals.models import Dog, Cat, Bird urlpatterns = patterns('animals.views', url(r'^$', 'index', {},Dog._meta.app_label), ) dog=Dog() cat=Cat() bird=Bird() urlpatterns+=dog.build_generic_CRUD_urls(Dog) urlpatterns+=cat.build_generic_CRUD_urls(Cat) urlpatterns+=bird.build_generic_CRUD_urls(Bird) then you can create the templates, and get the urls like this: {{ object.get_absolute_url }} View {{ object.get_update_url }} Edit {{ object.get_delete_url }} Delete {{ dummy_object.get_create_url }} Create dummy_object is a quick and dirty solution until I find some better... With all these you can create 54 functional and low detail CRUDS in one hour. :D Enjoy!
- model
- url
- generation
Modifying the fields of a third/existing model class
You can extend the class **ModifiedModel** to set new fields, replace existing or exclude any fields from a model class without patch or change the original code. **my_app/models.py** from django.db import models class CustomerType(models.Model): name = models.CharField(max_length=50) def __unicode__(self): return self.name class Customer(models.Model): name = models.CharField(max_length=50) type = models.ForeignKey('CustomerType') is_active = models.BooleanField(default=True, blank=True) employer = models.CharField(max_length=100) def __unicode__(self): return self.name **another_app/models.py** from django.db import models from django.contrib.auth.models import User from this_snippet import ModifiedModel class City(models.Model): name = models.CharField(max_length=50) def __unicode__(self): return self.name class HelperCustomerType(ModifiedModel): class Meta: model = 'my_app.CustomerType' description = models.TextField() class HelperCustomer(ModifiedModel): class Meta: model = 'my_app.Customer' exclude = ('employer',) type = models.CharField(max_length=50) # Replaced address = models.CharField(max_length=100) city = models.ForeignKey(City) def __unicode__(self): return '%s - %s'%(self.pk, self.name) class HelperUser(ModifiedModel): class Meta: model = User website = models.URLField(blank=True, verify_exists=False)
- fields
- model
- helper
- change
local django model test
Sometimes you need to test some model features without a complete django app installation. Just play only with the model object. With these small script you have a complete in memory django installation. Some Links: http://www.djangosnippets.org/snippets/1044/ (en) http://www.jensdiemer.de/permalink/150/mein-blog/99/django-db-model-test/ (de) http://www.python-forum.de/viewtopic.php?f=3&t=15649 (de) See also: https://github.com/readevalprint/mini-django/
- model
- testing
- test
- local-test
Model with random ID
An abstract model base class that gives your models a random base-32 string ID. This can be useful in many ways. Requires a Django version recent enough to support model inheritance.
- model
- random
- model-inheritance
- id
- primary-key
Choices datatype for model
This class will automatically create a django choices tuple like this: STATUS_CHOICES = django_choices(Draft=1, Public=2, Closed=3) Additionally, it includes a method that converts the choices tuple to a dictionary. Like this: STATUS = STATUS_CHOICES.to_dict() Those types can come in handy when you need to use those magic values in your code. Best done within the model once so everyone can use it. Code based on: http://www.djangosnippets.org/snippets/455/. By the way, if you want to just have the method without having to convert to the newer syntax.. it's backward compatible. Just add django_choices in front of the first paren for your choices tuple.
- choices
- model
Validation for full e-mails (e.g. "Joe Hacker <[email protected]>")
Out of the box, Django e-mail fields for both database models and forms only accept plain e-mail addresses. For example, `[email protected]` is accepted. On the other hand, full e-mail addresses which include a human-readable name, for example the following address fails validation in Django: Joe Hacker <[email protected]> This package adds support for validating full e-mail addresses. **Database model example** from django import models from full_email.models import FullEmailField class MyModel(models.Model): email = FullEmailField() **Forms example** from django import forms from full_email.formfields import FullEmailField class MyForm(forms.Form): email = FullEmailField(label='E-mail address') I maintain this code in a [GitHub gist](https://gist.github.com/1505228). It includes some unit tests as well.
- forms
- model
- validation
- orm
- database
Change model field attribute in a DRY way
Change model field attributes from a abstract base classes model in a dry way.
- model
- field
- dry
Password Validation - Require Letters and Numbers - no regex
Simple password validation for user registration - requires that password be 7 or more characters and contain both letters and numbers. Original validation with regex approach developed by kurtis. Optimized no-regex version based on code from watchedman ran as fast or significantly faster on all systems on which we tested it.
- registration
- model
- regex
- user
- validation
- form
- password
ByteSplitterField
When you want to save integers to the db, you usually have the choice between 16-, 32- and 64-bit Integers (also 8- and 24-bit for MySQL). If that doesn't fit your needs and you want to use your db-memory more efficient, this field might be handy to you. Imagine you have 3 numbers, but need only 10 bit to encode each (i.e. from 0 to 1000). Instead of creating 3 smallint-fields (48 bit), you can create one 'ByteSplitterField' which implements 3 'subfields' and automatically encodes them inside a 32 bit integer. You don't have to take care how each 10-bit chunk is encoded into the 32-bit integer, it's all handled by the field (see also field's description). Additionally, the Field offers opportunity to use decimal_places for each of your subfields. These are 'binary decimal places', meaning the integer-content is automatically divided by 2, 4, 8, etc. when you fetch the value from the field. You can also specify how values are rounded ('round' parameter) and what happens when you try to save a value out of range ('overflow' parameter) Not implemented (maybe in the future if I should need it sometime): * signed values. All values are positive right now! * real (10-based) decimal places (actually you could probably directly use DecimalFields here) * further space optimization, i.e. saving into CharField that's length can be chosen byte-wise
- model
- db
- database
- field
- custom
- custom-model-field
- IntegerField
- multibit-field
- model-field
TinyIntegerField
Django lacks support of MySQL's "tinyint" 8-bit-integer datatype. This snippet gives you a TinyIntegerField and a PositiveTinyIntegerField. Falls back Django's SmallIntegerField if a different database-engine is used
- model
- db
- 8-bit-integer
- MySQL
- IntegerField
- tiny-integer