create_c
Instead of creating a dictionary on every view everytime you could do this and just call it like c = create_c(request)
- templates
- request
- data
- csrf
Instead of creating a dictionary on every view everytime you could do this and just call it like c = create_c(request)
Just like it says -- set it up and run. Use it for server migrations, for project handoffs, in cron jobs, you name it. I have never had problems exporting models to individual fixtures in this way, and only one bout of trouble re-importing them (and that was, like, an impossible-triangle of OneToOneField dependencies anyway, and they were going from a sqlite file to a postgres schema that totally had inappropriate nullable columns in it). I find that the json files named for what they contain is helpful when and if manage.py does freak out during an import, as the output from `loaddata` command is so opaque it's autistic, basically. A trivial refactoring effort could make it into a management command -- it already makes use of the builtin `dumpdata` command class internally. However I did not feel like overthinking it enough to set it up in a repository (doubtlessly padded with unrelated 'utilities' and explanatory .rst files) and then writing a blog post to sell it to you. That is why you are reading this code here, instead of on GitHub. Don't get me wrong, GitHub is awesome, and like a consummate host... but not the way I love me some quick and dirty snippet code, these days. Whatever, you say lazy, I say productively relaxed, potato/potahto. Erm. In any case please do enjoy this model fixture-exporter. Yes.
Just a dump of a countries data, including standard codes & dial-codes, based on the following model: - Country -- name : CharField -- code : CharField -- dial_code : CharField Note that countries aren't unique, as some may have several intl. dial codes. You can parse it using script or load it using the loaddata command.
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
Allows you to dynamically maintain a local_constants.py file from a migration tool like South. Example of usage: set_constant('/home/projects/sample/local_constants.py', 'STAMP_MW_ID', 42, 'Set from sample.0007_add_constants.py') More more information, see [Allows you to dynamically maintain a local_constants.py file from a migration tool like South. Example of usage: set_constant('/home/projects/sample/local_constants.py', 'STAMP_MW_ID', 42, 'Set from sample.0007_add_constants.py') More more information, see [http://menendez.com/blog/maintain-contants-through-south-data-migration/](http://menendez.com/blog/maintain-contants-through-south-data-migration/).
This is a basic view for exporting data from models. It is designed so that you can provide the GET variables used for searching/filtering within listdisplay pages in the admin, and the code will filter the same way. It allows ouputting of model data in various formats using serializers. This should be used as a urlpattern through get_url, so that you can use the admin_view decorator to properly secure the data.
This is a basic model view for exporting data from models. It is designed so that you can provide the GET variables used for searching/filtering within listdisplay pages in the admin, and the code will filter the same way. It allows the output of model data in various formats using serializers or templates.
Django's serializer has some limitations which makes it a bit of a pain to use. Basically it will ignore any atributes that have been added to a model object. The code below is for an alternative serializer. This version allows you select what attributes will be serialized on a per object basis. It also allows you to either serialize the data into json or xml. The original json encoder was written by [Wolfram Kriesing](http://wolfram.kriesing.de/blog/) Example Usage: dumper = DataDumper() dumper.selectObjectFields('class_name',[...fields...]) dumper.selectObjectFields('class_name',[...fields...]) dumper.dump(model_instance,'xml') dumper.dump(model_instance,'json') dumper.dump(queryset,'xml')
Another sample of how to integrate Django and jQuery. === This starts a function in views.py that takes a long time to finish. It sets a session variable so that another function can report on the situation. We use jquery and ajax to 'pull' that data from Django so as to provide a progress report. I don't yet know how to background a long-running process, but this is an okay stop-gap method to use. I hope. \d
This creates a fixture in the form of a python script. Handles: 1. `ForeignKey` and `ManyToManyField`s (using python variables, not IDs) 2. Self-referencing `ForeignKey` (and M2M) fields 3. Sub-classed models 4. `ContentType` fields 5. Recursive references 6. `AutoField`s are excluded 7. Parent models are only included when no other child model links to it There are a few benefits to this: 1. edit script to create 1,000s of generated entries using `for` loops, python modules etc. 2. little drama with model evolution: foreign keys handled naturally without IDs, new and removed columns are ignored The [runscript command by poelzi](http://code.djangoproject.com/ticket/6243), complements this command very nicely! e.g. $ ./manage.py dumpscript appname > scripts/testdata.py $ ./manage.py reset appname $ ./manage.py runscript testdata
10 snippets posted so far.