Re: Renaming sequences

--000000000000e1b47e059b3d643c
Content-Type: text/plain; charset="UTF-8"

glad to hear its working without issue,  and your wife enjoyed my humor.
some others did not ;-)

This is one of the many reasons I do not like ORM's  it makes some things
easier but in many ways its makes things allot harder.  ORM's
complicate/clutter the DB with unnecessary Foreign Keys and relationship
checks that it must have so its logic does not break yet SQL would not
care..

When migration time comes around it goes so horrible sideways such as your
experience


On Thu, Jan 2, 2020 at 6:02 PM Mike Dewhirst <[email protected]> wrote:

> 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
>
>

--000000000000e1b47e059b3d643c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>glad to hear its working without issue,=C2=A0 and you=
r wife enjoyed my humor.=C2=A0 some others did not ;-)<br></div><div><br></=
div><div>This is one of the many reasons I do not like ORM&#39;s=C2=A0 it m=
akes some things easier but in many ways its makes things allot harder.=C2=
=A0 ORM&#39;s complicate/clutter the DB with unnecessary Foreign Keys and r=
elationship checks that it must have so its logic does not break yet SQL wo=
uld not care..=C2=A0 <br></div><div><br></div><div> When migration time com=
es around it goes so horrible sideways such as your experience <br></div><d=
iv><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">On Thu, Jan 2, 2020 at 6:02 PM Mike Dewhirst &lt;<a href=3D"ma=
ilto:[email protected]">[email protected]</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF">
    <div>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=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>as the saying goes &quot;can not see it from house&quot;, or &=
quot;when it
          breaks you keep both pieces&quot;.=C2=A0=C2=A0=C2=A0 (hope my hum=
or comes across)<br>
        </div>
      </div>
    </blockquote>
    <br>
    My wife also thought that was funny :)<br>
    <br>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>ORM=C2=A0 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=C2=A0 to double check=C2=A0 ORM does control=
 the
          naming=C2=A0 see</div>
        <div><a href=3D"https://github.com/django/django/blob/master/django=
/db/backends/postgresql/schema.py" target=3D"_blank">https://github.com/dja=
ngo/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=3D"cite">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div> Postgresql auto naming=C2=A0 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&#39;t an
    ORM problem but rather an app design and auto-migration problem. I
    began the project using Django&#39;s contributed auth app with its user
    model. This pre-dated Django&#39;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&#39;m happy<br>
    <br>
    Cheers<br>
    <br>
    Mike<br>
    <br>
  </div>

</blockquote></div>

--000000000000e1b47e059b3d643c--