Re: Auto Increment Primary_Key

[Rakesh Sinha]

Thanks for replying.
By rework you mean i need to change the schema. I have production data in
the existing table where i have to add the primary key. With approach 1, we
have been able to get everything working except tests as it doesnt create
the sequence and triggers.
Approach 2 works fine but the performance is very slow, any idea why the
query takes too long to execute. There is no error but only performance
issue.

On Sun, Sep 19, 2010 at 1:49 AM, Mike Dewhirst wrote:

> This might not work for you but I would consider South.
>
> You might be able to rework the schema and migrate the data.
>
>
>
> On 19/09/2010, at 4:40 PM, "hellowrakesh...@gmail.com" <
> hellowrakesh...@gmail.com> wrote:
>
> > Hi,
> > I am in a trouble and need help. We have an application developed in
> > Django and has a custom defined (Char Type) primary key. Due to few
> > new features, we need to change the primary key to a AutoGenerated
> > Key. We manually added a column named id, a sequence and a trigger
> > (same naming convention as Django creates since doing syncdb for
> > existing tables doesn't work). The problem the we are facing is-
> > 1) The application works fine when "id" is added in the Job class in
> > models (models.CharField(max_length=200, primary_key=True)). While
> > saving, a job object, job.id or job.pk  (job is the model name)
> > returns None although "id" is generated in Db.
> > 2) If we remove "id" from Job class (w/o removing the db column,
> > sequence and trigger), the application works fine but its extremely
> > slow. The query which takes .08 seconds is taking 31 seconds to
> > execute. We face the same issue, if we replace the "id" as AutoField.
> > The performance is very slow.
> >
> > We can live with approach 1 but while running unit tests, it fails
> > since it doesnt create the sequence and trigger on its own (note in
> > approach 1, auto field is not specified) and by specifying auto field,
> > tests work fine but the application is very slow.
> >
> > We need to fix this and its a bottle neck for us now. Any help on this
> > will be highly appreciated.
> > Thanks in advance.!
> >  Rakesh
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "Django users" group.
> > To post to this group, send email to django-us...@googlegroups.com.
> > To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com
> .
> > For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>


-- 
Rakesh Sinha

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Auto Increment Primary_Key

[Rakesh Sinha]

Thanks. I added the fields and wrote a Db migraton script to populate the
primary key and update all foreign key references. Everything works fine
except the tests. By just removing "id" from model class application as well
as tests work but performance is very slow. I will have a look at south as
well.

On Sun, Sep 19, 2010 at 1:57 AM, Shawn Milochik  wrote:

> Did you do any database migrations, or just add the new field?
>
> Just adding the new field to the model doesn't undo the groundwork laid by
> your original syncdb, which has set up the other field as the primary key in
> the database itself. Although your Django model is the way you want it, your
> database almost certainly is not.
>
> http://south.aeracode.org/
>
> South should help you do what you want. You'll probably need to do it in
> multiple steps. I've not had to switch around primary keys in a Django
> project yet, so hopefully someone else will weigh in on this. But it'll look
> something like the following:
>
> 1. Add the new auto-number field in a schema migration (leave out "primary
> key" bit for now).
> 2. Remove "primary key" from the old field and add it to the new field, and
> create another schema migration from this.
> 3. Delete the old field (if desired) from the model and run another schema
> migration.
>
> All this is assuming that no other models have a foreign key reference to
> this model -- that will require a lot more work.
>
> If all else fails, you could create a whole new model, create a data
> migration with South to transfer all the data from the old model, then
> delete the old model. Hopefully you can get by without doing that, but if
> your production database is in an uncertain state then it may be safer.
>
> Shawn
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>



-- 
Rakesh Sinha

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.