Django Admin change "history" logs
As you know Django Admin's sidebar shows a list of APP > MODELS. When you click on a MODEL, the focus area displays a list of RECORDS. Click on a RECORD, then the focus area shows a single RECORD as a form which you can change.
Here, in the upper right hand corner of the change form, is a gray pill-shaped button labeled "HISTORY" with entries like:
Dec. 9, 2021, 4:38 p.m. me Changed Table price headers.
Feb. 26, 2022, 2:06 p.m. me Changed Table date headers.
What I need is a copy of the record data before each change. Later, I need to query the Django database and--in this example--get the version of the record prior to the Feb 26 change.
How can Django Admin change "history" logs be used to also store copy of data?
Not for every Django Model
The rest of the Models & Records in Django Admin should behave normally. I only have a few Models where I need history log and data.
Not to be confused with model history
When discussing this with other Django developers I have to explain the history I need is for the record's data, and not the model. There is a third-party Django packages which does the other thing which I don't need.
Why do I need this?
In my Django site I run a script which requires settings. I'm querying a non-Django-related MongoDB database where I keep a copy of reports generated by several third-party vendors. To help me manage and utilize this data I need a record of each report's headers or schema.
There is a tight coupling between the data I'm storing in Mongo and the data's schema. For this reason I'm storing these headers as "settings" in Django's database. It's been really convient for me to use the Django Administration page to update these schema settings.
However, once in a blue moon a third-party will rename a header or add a new column to their report. When this happens I have to update the settings record in the Django Admin. Currently I don't have access to the historical schemas in my Django project, and have to write custom scripts to access historical data.
My wish is store each version of these records, so I can check the settings change history log. When the requested records needs a historical schema, I can then query the Django database to recall the valid headers for the date range.
Have you tried django-simple-history? Works fine for me.
Related
Using Django 1.9's Admin site, it is possible to view the change history for Model objects using the History button. When a change is made and logged in History, right now it only shows me the Action, for example "Changed description." is there a way to customize the fields in the History list to show the previous value of the field as well as what it was changed to? For example, "Changed x to y."
Thank you!
Django-admin does not offer a full-featured auditing history of your models. Instead you have to rely to a app like django-reversion (https://github.com/etianen/django-reversion) or django-simple-history (https://github.com/treyhunner/django-simple-history). One difference between these is that django-reversion keeps a JSON object for each version of the file, while django-simple-history creates a seperate history table - so django-reversion has a more compact representation of each version while django-simple-history offers easier older version querying.
I've also written an introductionary article about django-model auditing that may be useful # https://spapas.github.io/2015/01/21/django-model-auditing/
Django does keep a history of changes made. If you want to access that history in the django_admin_log this will be of use to you to add it to your own admin
http://djangoweekly.com/blog/post/viewbrowse-all-django-admin-edits-recent-actions-listing
I updated my OsCommerce shop to 2.3.3.4:
I replaced all files with the new default files from the package.
I Updated the old database with the script here: https://stackoverflow.com/a/19806818/1069083
Compared an sql-dump of the old database with the dump of an empty new database, It looked all OK.
Now the new version works with all products in it, but although I activated the "Categories" box in the admin interface it is not shown on the left.
Did I forget a Detail?
I found out why:
there are two different configure.php files, one is in
catalog/includes/configure.php
and one is in
catalog/admin/includes/configure.php
I didn't set the database to the new database in the admin config file, so all changes in admin didn't affect the real shop
I have a django project, in one of admin pages I'm adding data to the table
And I want after I choose one of themes, in Students name will be only students enrolled for this theme. How I can filter them by theme name?
Django does not do this out of the box. One third-party package I often see recommended to accomplish this common task (as opposed to writing your own ajax to do it) is django smart selects.
I inserted through SQL (manage.py dbshell) a handful of records. I then went to view the records in the Django admin interface. All of the records appeared, as expected.
However, any queries via Django (not direct SQL), did not return the records. Only after I went to a record through the admin interface, and clicked Save did the record appear in the query.
I'm new to Django, but after repeated searching and reading Django documentation, I did not find an answer. Any idea what is going on, and what can be done to make the SQL INSERT statements appear in queries without visiting each record to Save it through the admin interface?
Maybe you have to declare the transaction "dirty":
from django.db import transaction
transaction.set_dirty()
What would be the best way to port an existing Drupal site to a Django application?
I have around 500 pages (mostly books module) and around 50 blog posts. I'm not using any 3rd party modules.
I would like to keep the current URLS (for SEO purposes) and migrate database to Django. I will create a simple blog application, so migrating blog posts should be ok. What would be the best way to serve 500+ pages with Django? I would like to use Admin to edit/add new pages.
All Django development is similar, and yours will fit the pattern.
Define the Django model for your books and blog posts.
Unit test that model using Django's built-in testing capabilities.
Write some small utilities to load your legacy data into Django. At this point, you'll realize that your Django model isn't perfect. Good. Fix it. Fix the tests. Redo the loads.
Configure the default admin interface to your model. At this point, you'll spend time tweaking the admin interface. You'll realize your data model is wrong. Which is a good thing. Fix your model. Fix your tests. Fix your loads.
Now that your data is correct, you can create templates from your legacy pages.
Create URL mappings and view functions to populate the templates from the data model.
Take the time to get the data model right. It really matters, because everything else is very simple if your data model is solid.
It may be possible to write Django models which work with the legacy database (I've done this in the past; see docs on manage.py inspectdb).
However, I'd follow advice above and design a clean database using Django conventions, and then migrate the data over. I usually write migration scripts which write to the new database through Django and read the old one using the raw Python DB APIs (while it is possible to tie Django to multiple databases simultaneously, too).
I also suggest taking a look at the available blogging apps for Django. If the one included in Pinax suits your need, go ahead and use Pinax as a starting point.
S.Lott answer is still valid after years, I try to complete the analysis with the tools and format to do the job.
There are many Drupal export tools out of there by now but with the very same request I go for Views Datasource choosing JSON as format. This module is very solid and available for the last version of Drupal. The JSON format is very fast in both parsing and encoding and it's easy to read and very Python-friendly (import json).
Using Views Datasource you can create a node view sorted by node id (nid), show a limited number of elements per page, configure a view path, add to it a filter identifier and pass to it the nid to read all elements until you get an empty JSON response.
When importing in Django you have a wide set of tools as well, starting from loaddata to load fixtures. Views Datasource exported JSON but it's not formatted as Django expects fixtures: you can write a custom admin command to do the import, where you can have the full control of the import flow.
You can start your command passing a nid=0 as argument and then let the procedure read, import and then fetch data from the next page passing simply the last nid read in the previous HTTP request. You can even restrict access to the path on view but you need additional configuration on the import side.
Regarding performance, just for example I parsed and imported 15.000+ nodes in less than 10 minutes via a Django 1.8 custom admin command on an 8 core / 8 GB Linux virtual machine and PostgreSQL as DBMS, logging success and error information into a custom model for each node.
These are the basics for import/export between these two platform, for detailed information I described all the major steps for export from Drupal and then import to Django in this guide.