Model Forms: Clean unique field

Often I want fields in my models to be unique - Django's `unique` works too late in model form validation and will throw an exception unless you check for it by hand. This is a bit of code that cleans up the boiler plate of checking if different fields are unique. Set `exclude_initial` to `False` if you want to raise an error if the unique field cannot be set to whatever value the instance had before. **Update** Thanks fnl for rightly pointing out that Django's `unique=True` does check for this - just make sure to pass `instance=obj` when you're initializing your forms. _HOWEVER_ a problem you'll typically run into with this is though you want a field to unique, you also want multiple entries to be able to be `blank`. This can help you!

• forms
• model
• unique
• model-forms

Sat 01 Aug 2015 Read More

Encryption Fields

This provides some basic cryptographic fields using pyCrypto. All encryption/decription is done transparently and defaults to use AES. Example usage: class DefferredJunk(models.Model): semi_secret = EncryptedCharField(max_length=255)

• model
• field
• encryption

Sun 14 Jun 2015 Read More

MarkdownTextField

A [common pattern in Django](http://code.djangoproject.com/wiki/UsingMarkup) is to create a TextField intended for Markdown text (i.e. description) and a companion non-editable TextField for storing the HTML version (i.e. description_html), so the Markdown converter need not be run for every page view. This snippet is a custom field which encapsulates this pattern in a single field which can automatically create and update its companion HTML field. Usage: class MyModel(models.Model): description = MarkdownTextField()

• model
• markdown
• field

Sun 26 Dec 2010 Read More

shortcut for saving newforms to model

I come up with this short cut of saving data from newforms to a model, for newforms that contains attributes from several models or some attributes that doesn't found in a model attributes

• newforms
• model

Sun 11 Jul 2010 Read More

DRY with common model fields

If you have many models that all share the same fields, this might be an option. Please note that order matters: Your model need to inherit from TimestampedModelBase first, and models.Model second. The fields are added directly to each model, e.g. while they will be duplicated on the database level, you only have to define them once in your python code. Not sure if there is a way to automate the call to TimestampedModelInit(). Tested with trunk rev. 5699. There is probably a slight chance that future revisions might break this.

• models
• model
• inheritance

Tue 02 Sep 2014 Read More

Generate Model Data. Lots of Options.

Generate model data with this django management command! Data is generated based off of the model field types. And will also correctly generate foreign key's to other randomly generated records for join tables. And generate images with random colors and random words in the image - for image fields. You can supply quite a few parameters that control how the data is generated. And you can control it per field, per model. Or you can supply your own callable function which you can return your own random data. **SEE THE DOCS / EXAMPLE IN THE CODE SNIPPET FOR AVAILABLE OPTIONS, AND HOW TO CONTROL GENERATED DATA PARAMETERS** You can generate data that looks like real content, without having to write fixtures and such. Just generate it! It can generate data for these types of fields: EmailField SlugField BooleanField DateField DateTimeField TimeField IntegerField DecimalField TextField CharField IPAddressField URLField SmallIntegerField PositiveSmallIntegerField PositiveIntegerField ImageField There are also a few callables included that you can use to generate this kind of data: zip, extended zip, hashkey and uuid It's also worth noting that I keep this project up to date on my own git repository. There are a few fonts you'll need if you want to generate imaages, included in my git repo. http://gitweb.codeendeavor.com/?p=dilla.git;a=summary

• model
• random
• data
• management
• command
• lipsum

Wed 15 Dec 2010 Read More

SearchableManager

A drop-in chainable manager for providing models with basic search features such as +/- modifiers, quoted exact phrases and ordering by relevance.

• search
• model
• manager
• queryset

Tue 20 Jul 2010 Read More

More readable Enumeration class for Django choices

We currently use two-level tuples to specify choices of a field in models or forms. But, because it has only (value, verbose name) pair, the readability is bad whenever we indicate a specific choice value in our Python codes. So I made a small class that does "magic" for this: A Named Enumeration. Instead of `myobj.status == 0`, use `myobj.status == STATUS.UNREVIEWED`, for example.

• choices
• model
• orm
• enumeration
• enum

Tue 20 Dec 2011 Read More

ManyToManyField no syncdb

**Sumary** M2M relation without creating table. Normally you should specify m2m only in *one* model, thus widgets for many-to-many relations will be displayed inline on whichever model contains the actual reference to the ManyToManyField. But if you want to be able to have widgets displayed on both form you need some tricks, for example using intermediary-models can help, but you will not get multiselect widget (and in case of inlining extra = multi). Also you can write your own form which takes care about adding widget (just 1 line) and setting default values and saving it (more than few lines of code). If you try ManyToManyField with same db_table specified, the only problem will be in syncdb (it will try to create two identical tables) and the only thing our class does is preventing creation of table for M2M, so in one model you should use ManyToManyField and in another ManyToManyField_NoSyncdb with the same db_table argument. **Example** So to have M2M widgets in both forms you can write: class User(models.Model): #... groups = ManyToManyField('Group', related_name='groups', db_table=u'USERS_TO_GROUPS') class Group(models.Model): #... users = ManyToManyField_NoSyncdb(User, related_name='users', db_table=u'USERS_TO_GROUPS')

• model
• field
• manytomany
• manytomanyfield
• syncdb

Thu 18 Aug 2011 Read More

Model manager with row caching

RowCacheManager is a model manager that will try to fetch any 'get' (i.e., single-row) requests from the cache. ModelWithCaching is an abstract base model that does some extra work that you'll probably want if you're using the RowCacheManager. So to use this code, you just need to do two things: First, set objects=RowCacheManager() in your model definition, then inherit from ModelWithCaching if you want the invalidation for free. If you are unusually brave, use the metaclass for ModelWithCaching and you won't even need the "objects=RowCacheManager()" line.

• get
• model
• manager
• model-inheritance
• caching

Sun 11 Jul 2010 Read More

Application-independent permalink to admin url for an object

You can import get_admin_url into your models module and create a property on a class: `admin_url = property(get_admin_url)`

• admin
• model
• url
• object

Thu 21 Jan 2016 Read More

Django Model Inheritance

This snippet shows an alternative and interesting way to do Model Inheritance in Django. For description of the code, follow the inline comments.

• model
• inheritance

Tue 16 Nov 2010 Read More

Pickled Object Field

*Incredibly useful for storing just about anything in the database (provided it is Pickle-able, of course) when there isn't a 'proper' field for the job:* A field which can store any pickleable object in the database. It is database-agnostic, and should work with any database backend you can throw at it. Pass in any object and it will be automagically converted behind the scenes, and you never have to manually pickle or unpickle anything. Also works fine when querying. **Please note that this is supposed to be two files, one fields.py and one tests.py (if you don't care about the unit tests, just use fields.py)**

• model
• db
• orm
• database
• pickle
• object
• field
• pickled

Fri 16 Sep 2011 Read More

Update only selected model fields

Watch out! Previous versions of this snippet (without the values list) were vulnerable to SQL injection attacks. The "correct" solution is probably to wait until [ticket 4102](http://code.djangoproject.com/ticket/4102) hits the trunk. But here's my temporary fix while we wait for that happy day. Django's model.save() method is a PITA: 1. It does a SELECT first to see if the instance is already in the database. 2. It has additional database performance overhead because it writes all fields, not just the ones that have been changed. 3. It overwrites other model fields with data that may be out of date. This is a real problem in concurrent applications, like almost all web apps. If you just want to update a field or two on a model instance which is already in the database, try this: update_fields(user, email='[email protected]', is_staff=True, last_login=datetime.now()) Or you can add it to your models (see below) and then do this: user.update_fields( email='[email protected]', is_staff=True, last_login=datetime.now()) To add it to your model, put it in a module called granular_update, then write this in your models.py: import granular_update class User(models.Model): email = models.EmailField() is_staff = models.BooleanField() last_login = models.DateTimeField() update_fields = granular_update.update_fields

• fields
• model
• save
• performance
• field
• update
• integrity
• consistency

Sun 11 Jul 2010 Read More

DRY with common model fields (another way)

Some time you want to add some common fields to a group of models, for example, in a **Generalization/Specialization** relationship. One could have a base model as the generalization class and specialized models with a foreign key to that base model with an unique attribute but I don't like it that way so, I just do this code to add some commons attributes to a lot of models. If you have many models that all share the same fields, this might be an option. The fields are added directly to each model, e.g. while they will be duplicated on the database level, you only have to define them once in your **python** code. This code is a cleaner way(I think!!!) to do it and will do the same that [this one](http://www.djangosnippets.org/snippets/317/). I hope this piece of code will be useful for you.

• models
• model
• dry
• common

Wed 17 Nov 2010 Read More