The 'fullhistory' branch has been lying dormant for a few months it seems (at least no commits to the django hosted branch) - so I've recently updated and implemented leftover functionality in a modified version of the branch.
It is undoubtedly imperfect, but it should work in common use cases that are checked by the included tests. The embedded docs should shed light on any differences. The code is available at [http://pineapple.binrock.net/django/ modelhistory.tar.bz2] The tar consists of just the contrib subdirectory, should extract directly into django/contrib and 'work out of the box.' It supports accounting on the following operations (through the ChangeLogManager): (1) Creation (2) Mutation (including reverts) (3) Deletion The method signature changed (slightly) to taste: - get_version(obj,rev) -> [Model]/None - get_version_by_date(obj,date) -> QuerySet/list() - get_history(obj,offset=0) -> QuerySet/list() - set_version(obj,rev) -> [Model]/None - restore_version(content_type,obj_id,rev) -> [Model]/None The current code also provides for determining the calling user (the django.contrib.auth.models.User who initiated the model change). This method works (*tilts head*) but is meant more as a placeholder until a better implementation is discussed/implemented. There are a few issues that I think should be considered: (1) it should probably provide some means (if end user-desired) of providing distinct tables for each revisioned object (for performance reasons) (2) although it seems to function properly when embedded directly as django.contrib.modelhistory, I noticed some issues where it appeared that multiple processes were calling the provided dispatcher.connect(...), in effect, doubling (or tripling) the changelog output when installed as an app. With regard to (1), we have syncdb hooks and <model>_log could be autogenerated; however, (1) might be best served when coupled with a distinct subsystem that manages backend-specific logic - i.e., django/ multi-db allowing for a separate archival database, in which case this discuession would require a much broader consensus/design points. Hopefully, these issues can be dealt with quickly, and this (imho) highly useful contrib app can be fast-tracked. As always, feedback(being-put-in-my-place) greatly appreciated. -Thom Linton --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
