Uros Trebec wrote:
> > Sounds nice, this is a feature I'm currently looking for... but I've
> > already started my own implementation.
>
> Nice! Do you have anyting in code yet? Any bottlenecks?
>
sorry not yet. But will come, I need it for my current development.
>
> > I would just share it with you.
> >
> > I've build a single table History with :
> > - "change"; a text field which will contain a python pickled
> > dictionary: { field: old_value} in case you update a record.
>
> How does this help/work? Why dictionary? Can you explain?
>
I should add first that my history table can contain history of any
other table. In fact I don' t have an history table per "master" table.
This is a kind of "generic" history, thus I don't know the type of data
I will save in it. I solve this by pickling the data and save them into
a textField, that's the goal of the "change" field.
For flexibility reasons, I let possibility to select the field people
want to have in their history table.
Does this is better explained ?
> > - type: type of modification (update, delete, insert).
>
> Is this really necesary? How do you make use of it?
>
I take inspiration from svn log files. Sure this is necessary!!.
History is a kind of record trace from his creation up to his delete
(if occurs). But I'm agreed that most of the case, "insert" and
"update" are really useful. Concerning the "delete", this would be
useful if you want to have "undo" functionalities.
> > - "obj": the table object. This can come from ContentType
>
> I don't understand...
>
As I've explained, my "history table" can record history data of any
table I'm interested. Thus "obj" and "obj_id" give me possibility to
build a link between the history and the "master table".
> > - "obj_id": the id of the impacted object.
> > - create_date: a timestamp automatically set.
>
>
> > I'm using it by sub-classing the save methods in each model I want to
> > see the history.
> > This is quite flexible, because you can decide which field you want to
> > track.
>
> I agree. But I fail to see the need for not versioning the whole record/row.
>
>
> > To facilitate, yet one step further, it would be nice to have a
> > PickledField within Model.models of django.
>
> Can you elaborate on that?
behind the scene, Django will unpickle and pickle when you access the
data in a PickleField. This will avoid to have a model like this:
class History(models.Model):
change = TextField()
def get_change(self):
return loads(change)
def set_change(self,data):
change = dumps(data)
Imagine you have 3 fields with Pickling functionalities in the same
table ...
>
>
> > Feedbacks are welcome.
>
> Same here! :) And thanks for your feedback!
>
Thanks for the questions. I hope I'm a bit clearer ;-).
I hope I'll have a bit time this week to tackle this problem, and come
with real code.
William
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
