If you inherit from ValidatedModel instead of from models.Model, then full_clean() will be called before save(). So, add validators to your field definitions, and all your fields will be validated before they go to the database. The same thing can be accomplished with a pre_save signal, but the code is quite a bit messier than the simple inheritance above.
Save method, useful for automate pdf files creation if you want to use the file in database.
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
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
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.
This code provides a mixin and decorator which, when used together, can provide advisory locking on model methods. It provides locking by using MySQL's advisory lock system. See the example at the bottom of the code. This is a convenient and easy way to guarantee your model methods have exclusive access to a model instance. The LockableObjects class requires a MySQL backend, but it could be modified to use other back-end locking systems. The lock name generation in `LockableObject.get_lock_name()` could be altered to create much more complex locking schemes. Locking per-object, per-method for example.. Lock attempts have a timeout value of 45 seconds by default. If a timeout occurs, EnvironmentError is raised. **See the bottom of the script for an example** > **Instructions:** * **1:** Place the code in locking.py somewhere in your path * **2:** In your models.py (or any script with an object you want to lock): `from locking import LockableObject, require_object_lock` * **3:** In the model you want locking for, add the `LockableObject` mixin * **4:** Decorate the method you want to be exclusively locked with `@require_object_lock`
This class makes easier the job of rendering lists of model instances in django templates. It's intended to mimic the behavior of the Model Forms in that it contains the code needed to render it as an HTML table and makes it easy to handle all the model lists from a single view (as it's usually done with the generic views for creating and updating model instances). It also supports pagination and provides hooks for subclassing and customizing the rendered fields, column titles and list order. Basic example: `class Account(Model):` `name = models.CharField(max_length=MAX_LENGTH)` `responsible = models.CharField(max_length=MAX_LENGTH)` `email = models.EmailField()` `class AccountModelList(ModelList):` `class Meta:` `model = Account` `fields = ['name', 'responsible'] #email won't get a column` The model list would be instantiated with something like: `model_list = AccountModelList(instances=account_queryset)` Then a table header can be rendered with model_list.as_table_header(), while the table rows can be rendered calling as_table() on each model_list.items element.
Riffing on http://djangosnippets.org/snippets/1024/ I didn't want a graph; I just wanted to see what depended on a specific model. This does that nicely.
Small changes to [Snippet 1694](http://djangosnippets.org/snippets/1694/) to that QueryAPI works for django 1.2 and higher. Changes: * Replaced `get_db_prep_value` with `get_prep_value`. * Replaced `get_db_prep_lookup` with modified `get_prep_lookup`.
serialize model object to dict with related objects
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!
Add to ModelForm the ability to declare inline formsets. Check the docstring for an in-depth example.
Requires [PyISBN](http://pypi.python.org/pypi/pyisbn/0.5.2). Use like so: class Book(models.Model): title = models.TextField() isbn = ISBNField() ... the link in the widget can be changed to amazon, borders, you name it. If the DB version is a 13-digit ISBN, the display box contains the 10-digit, labeled; and vice-versa.
Many of my projects heavily depend on other non-django projects to create the databases. To simplify setting up a test environment, I modified the simple test runner so that it will treat all models as managed. This will also allow for easier test set up against models that point to views. You can directly populate the view with the specific data needed for the tests, instead of populating (potentially) several models.
This snippet provides a uuid field for models, improving on the work in http://www.djangosnippets.org/snippets/335/