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

Wed 05 Oct 2011 Read More

Custom 'save' method, automate creating pdf file from entry.

Save method, useful for automate pdf files creation if you want to use the file in database.

• model
• pdf
• save
• reportlab

Wed 28 Sep 2011 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

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

Sat 27 Aug 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

adding fields to User model

This code adds new field to Django user model. It must be executed early as much as possible, so put this code to __init__.py of some application.

• fields
• model
• user
• auth
• field

Thu 18 Aug 2011 Read More

Read only form & model field

These decorators can be used to make some model/form fields readonly. **Sample usage:** # Use this decorator on form with readonly fields.` @modelform_with_readonly_fields` class FooAdminForm(forms.ModelForm):` ... # This decorator shoud be used to protect selected fields ` # from modification after initial save.` @has_readonly_fields` class Foo(models.Model):` read_only_fields = ('name', )` ... **Result** will be the same as shown in this post: [Readonly field](http://stackoverflow.com/questions/324477/in-a-django-form-how-to-make-a-field-readonly-or-disabled-so-that-it-cannot-be/1424453#1424453) and [Readonly model field](http://www.djangozen.com/blog/read-only-fields-in-models)

• forms
• model
• field
• readonly

Fri 12 Aug 2011 Read More

Update timestamp If any instance field has changed

Needed a function to check if any field in an instance has changed. If so update a datetime field to now to keep track of changes. This function is an override of the save function in the model.

• fields
• model
• save
• field
• method
• instance
• override
• compare

Fri 05 Aug 2011 Read More

Random object IDs using an abstract base model

To put obfuscated primary keys in any class, simply inherit from this one. For example: class Offer(ObfuscatedPKModel) You can match for these bigint primary keys in your urls.py like this: '^offer/(?P<offer_pk>[0-9\-]+)$'

• models
• model
• random
• abstract
• primary-key
• obfuscation
• obfuscated
• ID

Wed 20 Jul 2011 Read More

Custom optional abstract base attributes

I needed an abstract base class that can add attributes to the child classes based on the child's name. The attributes had to be implicit, but overridable, so all derived classes would get them by default, but they could be easily overriden in the child definition. So, the code code I came up with basically consists of a customized metaclass used by the abstract model.

• model
• abstract

Sat 09 Jul 2011 Read More

StateField

Based on [CountryField](http://www.djangosnippets.org/snippets/494/).

• model
• field
• state
• statefield

Sat 25 Jun 2011 Read More

Improved Pickled Object Field

[Based on snippet #513 by obeattie.](http://www.djangosnippets.org/snippets/513/) **Update 10/10/09:** [Further development is now occurring on GitHub, thanks to Shrubbery Software.](http://github.com/shrubberysoft/django-picklefield) 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. `PickledObjectField` is database-agnostic, and should work with any database backend you can throw at it. You can pass in any Python object and it will automagically be converted behind the scenes. You never have to manually pickle or unpickle anything. Also works fine when querying; supports `exact`, `in`, and `isnull` lookups. It should be noted, however, that calling `QuerySet.values()` will only return the encoded data, not the original Python object. *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).* This PickledObjectField has a few improvements over the one in [snippet #513](http://www.djangosnippets.org/snippets/513/). 1. This one solves the `DjangoUnicodeDecodeError` problem when saving an object containing non-ASCII data by base64 encoding the pickled output stream. This ensures that all stored data is ASCII, eliminating the problem. 2. `PickledObjectField` will now optionally use `zlib` to compress (and uncompress) pickled objects on the fly. This can be set per-field using the keyword argument "compress=True". For most items this is probably **not** worth the small performance penalty, but for Models with larger objects, it can be a real space saver. 3. You can also now specify the pickle protocol per-field, using the protocol keyword argument. The default of `2` should always work, unless you are trying to access the data from outside of the Django ORM. 4. Worked around a rare issue when using the `cPickle` and performing lookups of complex data types. In short, `cPickle` would sometimes output different streams for the same object depending on how it was referenced. This of course could cause lookups for complex objects to fail, even when a matching object exists. See the docstrings and tests for more information. 5. You can now use the `isnull` lookup and have it function as expected. A consequence of this is that by default, `PickledObjectField` has `null=True` set (you can of course pass `null=False` if you want to change that). If `null=False` is set (the default for fields), then you wouldn't be able to store a Python `None` value, since `None` values aren't pickled or encoded (this in turn is what makes the `isnull` lookup possible). 6. You can now pass in an object as the default argument for the field without it being converted to a unicode string first. If you pass in a callable though, the field will still call it. It will *not* try to pickle and encode it. 7. You can manually import `dbsafe_encode` and `dbsafe_decode` from fields.py if you want to encode and decode objects yourself. This is mostly useful for decoding values returned from calling `QuerySet.values()`, which are still encoded strings. The tests have been updated to match the added features, but if you find any bugs, please post them in the comments. My goal is to make this an error-proof implementation. **Note:** If you are trying to store other django models in the `PickledObjectField`, please see the comments for a discussion on the problems associated with doing that. The easy solution is to put django models into a list or tuple before assigning them to the `PickledObjectField`. **Update 9/2/09:** Fixed the `value_to_string` method so that serialization should now work as expected. Also added `deepcopy` back into `dbsafe_encode`, fixing #4 above, since `deepcopy` had somehow managed to remove itself. This means that lookups should once again work as expected in **all** situations. Also made the field `editable=False` by default (which I swear I already did once before!) since it is never a good idea to have a `PickledObjectField` be user editable.

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

Tue 21 Jun 2011 Read More

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

Mon 13 Jun 2011 Read More

Modeli18n

This is a Model base class used to support internationalization (i18n) for your models. This code extends the Django's Model class so you can use all available options from Model safely. Basicly, it uses introspection to create a sub-model to your model to hold translation. **Features:** 1. Simplicity of use. You simply extend your model with this class and add all the fields that needs to be translated are placed under the `locale` sub-class; 2. The code uses the `django.utils.translation.get_language()` to select the current language; 3. You can use `python ./manage.py syncdb` command safely; 4. Force the user to enter a translation for each language even if the fields can be blank. This makes sure that all objects are returned safely. **Ordering by locale fields:** To sort on translated fields, use the form of "model_i18n__transfieldname" (see code for example). **Limitation:** Do not use localized fields in __unicode__, the admin will throw an exception when you'll add a new item and do "save and continue". Just drop a comment if you need more information. (last update: 06/15/2010)

• internationalization
• i18n
• model
• locale
• translation
• culture

Fri 22 Apr 2011 Read More

Faster pagination / model object seeking (10x faster infact :o) for larger datasets (500k +)

ModelPagination Designed and Coded by Cal Leeming Many thanks to Harry Roberts for giving us a heads up on how to do this properly! ---------------------------------------------------------------------------- This is a super optimized way of paginating datasets over 1 million records. It uses MAX() rather then COUNT(), because this is super faster. EXAMPLE: >>> _t = time.time(); x = Post.objects.aggregate(Max('id')); "Took %ss"%(time.time() - _t ) 'Took 0.00103402137756s' >>> _t = time.time(); x = Post.objects.aggregate(Count('id')); "Took %ss"%(time.time() - _t ) 'Took 0.92404794693s' >>> This does mean that if you go deleting things, then the IDs won't be accurate, so if you delete 50 rows, you're exact count() isn't going to match, but this is okay for pagination, because for SEO, we want items to stay on the original page they were scanned on. If you go deleting items, then the items shift backwards through the pages, so you end up with inconsistent SEO on archive pages. If this doesn't make sense, go figure it out for yourself, its 2am in the morning ffs ;p Now, the next thing we do, is use id seeking, rather then OFFSET, because again, this is a shitton faster: EXAMPLE: >>> _t = time.time(); x = map(lambda x: x, Post.objects.filter(id__gte=400000, id__lt=400500).all()); print "Took %ss"%(time.time() - _t) Took 0.0467309951782s >>> _t = time.time(); _res = map(lambda x: x, Post.objects.all()[400000:400500]); print "Took %ss"%(time.time() - _t) Took 1.05785298347s >>> By using this seeking method (which btw, can be implemented on anything, not just pagination) on a table with 5 million rows, we are saving 0.92s on row count, and 1.01s on item grabbing. This may not seem like much, but if you have 1024 concurrent users, this will make a huge difference. If you have any questions or problems, feel free to contact me on cal.leeming [at] simplicitymedialtd.co.uk

• model
• pagination
• object
• large
• big
• dataset
• faster
• optimized
• quicker
• seeking

Thu 24 Mar 2011 Read More