Login

3113 snippets

Snippet List

db_dump.py - for dumpping and loading data from database

Description ============= This tool is used for dump and restore database of Django. And it can also support some simple situations for Model changes, so it can also be used in importing data after the migration of Model. It includes: dump and restore. Dump ====== Command Line: python db_dump.py [-svdh] [--settings] dump [applist] If applist is ignored，then it means that all app will be dumped. applist can be one or more app name. Description of options: * -s Output will displayed in console, default is writing into file * -v Display execution infomation, default is does not display * -d Directory of output, default is datadir in current directory. If the path is not existed, it'll be created automatically. * -h Display help information. * --settings settings model, default is settings.py in current directory. It can only support Python format for now. It'll create a standard python source file, for example: dump = {'table': 'tablename', 'records': [[...]], 'fields': [...]} table' is table name in database, records is all records of the table, it's a list of list, that is each record is a list. fields` is the fields name of the table. Load(Restore) ¶ Command Line: python db_dump.py [-svdrh] [--settings] load [applist] You can refer to the above description for same option. Others is: * -r Does not empty the table as loading the data, default is empty the table first then load the data Using this tool, you can not only restore the database, but also can deal with the simple changes of database. It can select the suitable field from the backup data file according to the changed Model automatically, and it can also deal with the default value define in Model, such as default parameter and auto_now and auto_now_add parameter for Date-like field. And you can even edit the backup data file manually, and add a default key for specify the default value for some fields, the basic format is: 'default':{'fieldname':('type', 'value')} default is a dict, the key will be the field name of the table, the value will be a two element tuple, and the first element of this tuple is type field, the second element is its value. Below is a description of type field: type value description 'value' real value using the value field directly 'reference' referred field name the value of this filed will use the value of referred field. It'll be used when the field name is changed 'date' 'now'|'yyyy-mm-dd' It's a date date type, if the value field is 'now', then the value be current time. Otherwise, it'll be a string, it's format is 'yyyy-mm-dd' 'datetime' 'now'|'yyyy-mm-dd hh:mm:ss' The same as above 'time' 'now'|'hh:mm:ss' The same as above The strategy of selection of default value of a field is: first, create a default value dict according the Model, then update it according the default key of backup data file. So you can see if there is a same definition of a field in both Model and backup data file, it'll use the one in backup data file. According the process of default value, this tool will suport these changes, such as: change of field name, add or remove field name, etc. So you can use this tool to finish some simple update work of database. But I don't give it too much test, and my situation is in sqlite3. So download and test are welcome, and I hope you can give me some improve advices. project site ============= http://code.google.com/p/db-dump/

  • tool
  • dump
Read More

render_to_response wrapper

Simplifies using RequestContext in render_to_response. Simply call the wrapper with request as the first argument, and the rest of the arguments are as normal for render_to_response. ex: render_response(request, 'foo_list.html', {'foo': Foo.objects.all()})

  • render_to_response
  • requestcontext
  • shortcut
  • template
Read More

render_to

Decorator, written for views simplification. Will render dict, returned by view, as context for template, using RequestContext. Additionally you can override template, returning two-tuple (context's dict and template name) instead of just dict. Usage: @render_to('my/template.html') def my_view(request, param): if param == 'something': return {'data': 'some_data'} else: return {'data': 'some_other_data'}, 'another/template.html'

  • render_to_response
  • requestcontext
  • shortcut
  • decorator
  • rendering
Read More

Authenticate against Active Directory

I put this in a file called auth.py, then referenced it in the settings.py like so: AUTHENTICATION_BACKENDS = ('myproject.myapp.auth.ActiveDirectoryBackend',) This has been tested on my office network, with the following setup: Django 0.96 Python 2.4.4 python-ldap Fedora Core 5 (On the server hosting Django) AD Native Mode 2 Windows 2003 AD servers

  • auth
  • ldap
  • active-directory
  • backend
Read More

Decouple 'help_text' attribute from field definition

I found model definitions with large number of fields with long help_text unreadable and feel that help_text doesn't really belong to field definition. With this snippet help_text attributes can live outside field definitions in inner HelpText class so field definitions become shorter and more readable. Usage: from django.db import models import readable_models class MyModel(models.Model): __metaclass__ = readable_models.ModelBase name = models.CharField('Name', max_length=30) address = models.CharField('Address', max_length=255) # ... long list of fields class HelpText: name = 'The name ...' address = 'Example: <very verbose example is here>'

  • models
  • help_text
Read More

Overriding Third-party Admin

With the advent of newforms-admin it's now possible to override admin interfaces without having to change any code in third-party modules. This example shows how to enable a rich-text editor for `django.contrib.flatpages` without touching Django's code at all. (Actual embedding of the editor via Javascript left as an exercise for the reader – plenty of examples of that elsewhere.)

  • admin
  • newforms-admin
  • custom
  • contrib.admin
  • override
  • rich-text
Read More

Advanced Search in django admin

This is an example on how to create a custom advanced search (like the google advanced search page) in the admin app instead of the basic search field. you need to override 2 template of the admin so in your templates/admin folder copy the html files from the original admin app as follow: change_list.html: add the name of the module of the templatetag at the top where there is the load command from: {% load adminmedia admin_list i18n %} to: {% load adminmedia admin_list custom_search_form i18n %} and on line 87 (circa) you need to load our custom template tag something like: {% block search %}{% advanced_search_form cl %}{% endblock %} search_form.html: put your form inside the <form> tags with {{asf}} should be enough (I have also removed cl.value from the input text field because would be to complex to reload form values too ) probably would be better to create 2 new clean template and extend them but I'll leave that as an exercise for the reader :) many thanks to [Peter Baumgartner to get me in the right direction after his post](http://lincolnloop.com/blog/2011/jan/11/custom-filters-django-admin/) Currently ordering in the admin panel doesn't work if you find a way to get it work please write a comment

  • admin
  • advanced-search
  • model-filtering
Read More

Compact primary keys

If the primary key on a table is an integer, it can be desirable after a lot of adding and removing either during testing (as was my case) or otherwise, to tidy up the key space a little and see the primary keys run up as unbroken sequences from 1. An excellent snippet here: https://djangosnippets.org/snippets/2915/ showed us how change the primary key value from in a given table and in all tables that relate to it (have a foreign key pointing into it). We can exploit that to achieve this outcome with integrity. For any given table we just fetch the primary keys into a sorted list and then walk the list assigning key 1, 2, 3, 4 etc where needed (if it doesn't already have that key).Because our list is sorted we're always moving tuples down the ladder of available keys to next empty slot basically until we've compacted the whole list. And voila. Mission accomplished. Works in with database introspection, in part because the integrity of relations is a little obscured by the ORM which hides intermediary tables in ManyToMany relationships and such. At the database API level these concerns all disappear. Built and tested with Django 1.11 but the form only goes to 1.10 here. Not even sure it works on 1.10. Certainly the snippet I based it on didn't work in 1.11 and need some updating.

  • primary-key
  • compact
Read More

Automatic Memoization Decorator

This decorator will memoize the results of instance methods, similar to `django.util.functional.memoize`, but automatically creates a cache attached to the object (and therefore shares the life span of the object) rather than requiring you to provide your own. Note this is intended for instance methods only, though it may work in some cases with functions and class methods with at least one argument. This is useful for memozing results of model methods for the life of a request. For example: class MyModel(models.Model): #Fields here @auto_memoize def some_calculation(self): #some calculation here return result

  • cache
  • memoize
Read More

Profiling Middlware

Displays hotshot profiling for any view. http://yoursite.com/yourview/?prof Add the "prof" key to query string by appending ?prof (or &prof=) and you'll see the profiling results in your browser. It's set up to only be available in django's debug mode, but you really shouldn't add this middleware to any production configuration. * Only tested on Linux * You should probably use this one instead: http://djangosnippets.org/snippets/2126/

  • middleware
  • profile
  • debug
  • stats
  • performance
  • hotshot
Read More

Friendly ID(Python 3.X)

This is just modified version of [friendly id](https://djangosnippets.org/snippets/1249/) for make this script compatible with python 3.x Invoice numbers like "0000004" are a little unprofessional in that they expose how many sales a system has made, and can be used to monitor the rate of sales over a given time. They are also harder for customers to read back to you, especially if they are 10 digits long. This is simply a perfect hash function to convert an integer (from eg an ID AutoField) to a unique number. The ID is then made shorter and more user-friendly by converting to a string of letters and numbers that wont be confused for one another (in speech or text). To use it: import friendly_id class MyModel(models.Model): invoice_id = models.CharField(max_length=6, null=True, blank=True, unique=True) def save(self, *args, **kwargs): super(MyModel, self).save(*args, **kwargs) # Populate the invoice_id if it is missing if self.id and not self.invoice_id: self.invoice_id = friendly_id.encode(self.id) self.save() if self.id and not self.invoice_id When an object from this model is saved, an invoice ID will be generated that does not resemble those surrounding it. For example, where you are expecting millions of invoices the IDs generated from the AutoField primary key will be: obj.id obj.invoice_id 1 TTH9R 2 45FLU 3 6ACXD 4 8G98W 5 AQ6HF 6 DV3TY ... 9999999 J8UE5 The functions are deterministic, so running it again sometime will give the same result, and generated strings are unique for the given range (the default max is 10,000,000). Specifying a higher range allows you to have more IDs, but all the strings will then be longer. You have to decide which you need: short strings or many strings :-) This problem could have also been solved using a random invoice_id generator, but that might cause collisions which cost time to rectify, especially when a decent proportion of the available values are taken (eg 10%). Anyhow, someone else has now already written this little module for you, so now you don't have to write your own :-)

  • database
  • field-id
  • invoice-id
  • invoice
Read More