Re: Renaming sequences
Mike Dewhirst <[email protected]> Fri, 3 Jan 2020 10:02:42 +1100
| Newsgroups | gmane.comp.db.postgresql.novice |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--------------E9E4C03D336C6E6CAF4435BF
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Justin
I found this in my spam folder today as it came up for deletion.
On 19/12/2019 11:01 am, Justin wrote:
>
> as the saying goes "can not see it from house", or "when it breaks you
> keep both pieces". (hope my humor comes across)
My wife also thought that was funny :)
>
> ORM has to know the name of the sequence or it can not pre-fetch the
> sequence, or modify its values
>
> i went and looked to double check ORM does control the naming see
> https://github.com/django/django/blob/master/django/db/backends/postgresql/schema.py
>
> lines 10 -13 and line 96,
Yes. In the end I made the changes with scripted psql so the sequences
match what the ORM is looking for. Postgres seems less critical because
it appears to keep track of which sequence is used by which key field
when psql does the adjustment.
>
> Postgresql auto naming for indexes and sequences is
> tabel_column_type(idx,seq..) the ORM follows a similar logic
>
> changing names outside of the ORM will bugger the app
In this case I was trying to game the ORM because the django migration
system cannot relocate django_auth_user to myapp_common_user while
retaining existing content. This isn't an ORM problem but rather an app
design and auto-migration problem. I began the project using Django's
contributed auth app with its user model. This pre-dated Django's
current auth system with a swappable user table. New requirements forced
conversion of the user table so I can tweak a small portion of the auth
functionality.
Retro-fitting a swapped user table is v.difficult using the Django
migrations system but dead easy for a new project. Fortunately there are
plenty of giants out there to help midgets like me.
Thank you for your help
Everything is working and I'm happy
Cheers
Mike
--------------E9E4C03D336C6E6CAF4435BF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Justin<br>
<br>
I found this in my spam folder today as it came up for deletion.<br>
<br>
On 19/12/2019 11:01 am, Justin wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CALL-XeMhtNXRH-eLC1NEHKKYHOPmjv5_s87YzW+y8OAwWH-6wg@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>as the saying goes "can not see it from house", or "when it
breaks you keep both pieces". (hope my humor comes across)<br>
</div>
</div>
</blockquote>
<br>
My wife also thought that was funny :)<br>
<br>
<blockquote type="cite"
cite="mid:CALL-XeMhtNXRH-eLC1NEHKKYHOPmjv5_s87YzW+y8OAwWH-6wg@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>ORM has to know the name of the sequence or it can not
pre-fetch the sequence, or modify its values<br>
</div>
<div><br>
</div>
<div>i went and looked to double check ORM does control the
naming see</div>
<div><a
href="https://github.com/django/django/blob/master/django/db/backends/postgresql/schema.py"
moz-do-not-send="true">https://github.com/django/django/blob/master/django/db/backends/postgresql/schema.py</a></div>
<div><br>
</div>
<div>lines 10 -13 and line 96, <br>
</div>
</div>
</blockquote>
<br>
Yes. In the end I made the changes with scripted psql so the
sequences match what the ORM is looking for. Postgres seems less
critical because it appears to keep track of which sequence is used
by which key field when psql does the adjustment.<br>
<br>
<blockquote type="cite"
cite="mid:CALL-XeMhtNXRH-eLC1NEHKKYHOPmjv5_s87YzW+y8OAwWH-6wg@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div> Postgresql auto naming for indexes and sequences is
tabel_column_type(idx,seq..) the ORM follows a similar logic <br>
</div>
<div><br>
</div>
<div>changing names outside of the ORM will bugger the app<br>
</div>
</div>
</blockquote>
<br>
In this case I was trying to game the ORM because the django
migration system cannot relocate django_auth_user to
myapp_common_user while retaining existing content. This isn't an
ORM problem but rather an app design and auto-migration problem. I
began the project using Django's contributed auth app with its user
model. This pre-dated Django's current auth system with a swappable
user table. New requirements forced conversion of the user table so
I can tweak a small portion of the auth functionality. <br>
<br>
Retro-fitting a swapped user table is v.difficult using the Django
migrations system but dead easy for a new project. Fortunately there
are plenty of giants out there to help midgets like me.<br>
<br>
Thank you for your help<br>
<br>
Everything is working and I'm happy<br>
<br>
Cheers<br>
<br>
Mike<br>
<br>
</body>
</html>
--------------E9E4C03D336C6E6CAF4435BF--