On 01/02/2017 08:02 AM, Melvin Davidson wrote:
>
>
>
> *First, there is no need to make row_id's when you already have
> a valid
> primary key.
>
>
> In a perfect world yes, but this is a world with ORM's as I found
> out the hard way:
>
> https://docs.djangoproject.com/en/1.10/ref/models/fields/#primary-key
<https://docs.djangoproject.com/en/1.10/ref/models/fields/#primary-key>
>
> "The primary key field is read-only. If you change the value of the
> primary key on an existing object and then save it, a new object
> will be created alongside the old one."
>
>
>
> --
> Adrian Klaver
> adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>
>
>
> *>https://docs.djangoproject.com/en/1.10/ref/models/fields/#primary-key
> <https://docs.djangoproject.com/en/1.10/ref/models/fields/#primary-key>
> *
> *You are quoting from a django document. Please don't muddle the waters.
Not sure I follow. You said:
"First, there is no need to make row_id's ..."
I was just pointing out that this is not a hard and fast rule and that
sometimes you are required to come up with a compromise solution.
> So you are saying this will not work?
Yes, if you want to bypass the ORM and want to run into FK problems.
> UPDATE mytable
> SET mykey = 'new_value'
> WHERE mykey = 'old_value';
Under Django you would now have one row with the new_value and another
with the old_value. Assuming mytable has child tables that reference
mykey, the child tables would be still referencing the old_value.
>
> DELETE FROM mytable
> WHERE mykey = 'old_value';
What happens now depends on how you have CASCADING set up. In any case
you would be doing more work to bring the child tables back into sync
with the parent table. For me the easiest the thing to do was bow to the
ORM convention and put in an integer PK.
> *
> *Happy New Year Adrian*
>
> --
> *Melvin Davidson*
> I reserve the right to fantasize. Whether or not you
> wish to share my fantasy is entirely up to you.
--
Adrian Klaver
adrian.klaver@aklaver.com