I tried it out David, and it is simple and it works, I was just about
to make the same exact thing. Thank you!
On 4 okt, 15:21, David Hall <[EMAIL PROTECTED]> wrote:
> I've created a Google group for discussing possible improvements to the
> django-reversion project. The group is called 'django-
Hi Jonknee,
Thanks for the bug report, I've uploaded a patch which should take care
of that problem.
I've taken the liberty of inviting you to a django-reversion Google
discussion group. If you are interested in improving the system, I'd
love to hear your feedback and comments!
David.
jonk
I've created a Google group for discussing possible improvements to the
django-reversion project. The group is called 'django-reversion', and
is a good place to let your views be heard about enhancements to the system.
At some point I would like to put the project forward as a candidate for
t
I did consider such an approach, but this runs into a fair amount
confusion for things like model inheritance. Also, it would result in
vast quantities of database tables being created.
Likewise, custom fields would have to be treated carefully, as would
unique fields. Also if you have any M
That is exactly what i did for a project :)
When you register a model for versioning, automagicly a new model is
created which the original model + an 'version-control' abstract base model
to add things like version numbers, datetimestamps, methods to diff between
versions etc. Also all unique r
On Oct 1, 11:25 am, David Hall <[EMAIL PROTECTED]> wrote:
> I've just released an open-source version control application for
> Django. It is available for download from Google code.
Neat idea! I installed it and while it works for rolling back, it does
not work bring back deleted items. I did a
What if, for each model under version control, you'd create an
identical table (except the ID field would be a foreign key, not a
primary one). Any time a migration is run on that model, the same
migration could be run on the "twin" table, too.
Erik
On 02.10.2008, at 18:34, David Hall wrot
That is a problem, to be sure, and I'm not sure if a reasonable solution
exists.
As it stands, Django is currently lacking an automated rollback/recovery
for models. The fullhistory branch tried to address this lack, but
seems to have been abandoned for the time being.
django-reversions impl
But your schema's will most likely change over time. And sometimes in
significant ways which do not have a likely default; e.g. splitting a
full_name field into a first_name and last_name field or visa-versa.
Now after applying this change to the database, how will
django-reversions work when you
2008/10/2 David Hall <[EMAIL PROTECTED]>:
> Marek Stępniowski wrote:
>> How does django-reversion deal with relationships between Django models?
>>
>> Version-controlling relationships between entities is an Achilles heel
>> of such applications. I have read django-reversion docs on google code
>>
This is best explained by example.
Let's say you have two models, Foo and Bar, both under version control.
>>> class Bar(models.Model):
... pass
...
>>> class Foo(models.Model):
... bar = models.ForeignKey(Bar)
If you save an instance of Foo, then the primary key of the referenced
Ba
On Wed, Oct 1, 2008 at 5:25 PM, David Hall <[EMAIL PROTECTED]> wrote:
>
> I've just released an open-source version control application for
> Django. It is available for download from Google code.
>
> http://code.google.com/p/django-reversion/
>
> Features include:
>
> - Roll back to any point in
This discussion has been moved from django-developers.
To answer a pending question: This application is for tracking versions
of data, not performing database schema migrations. Thus:
- django-evolution concerns itself with maintaining versions of
database schemas.
- django-rever
13 matches
Mail list logo
