one patch to fix a Django 1.8 issue for merging legacy database

[Ben L]

Issue: I have an existing database, so the guide in 
https://docs.djangoproject.com/en/1.8/howto/legacy-databases/ to inspect db 
and created models.py . 

That table does NOT have an 'id' column, and the created models.py doesn't 
have 'id' either, and the class is unmanaged (managed=False). But when I 
use Django to create page, the system failed, saying the 'id' is not found 
in the table. Somehow the query included 'id' in the select fields.

After a little bit of digging, I changed 
/usr/local/lib/python2.7/dist-packages/django/db/models/options.py:
Old:
line 284-287:
else:
auto = AutoField(verbose_name='ID', primary_key=True,
auto_created=True)
model.add_to_class('id', auto)

New:
else:
if self.managed:
auto = AutoField(verbose_name='ID', primary_key=True,
auto_created=True)
model.add_to_class('id', auto)

Then my class will not get into this "AutoField" action to add 'id' in the 
query.

Looks like an apparent bug. This change works well for me. Please check and 
confirm whether this should be commit into you code base.

Thanks.


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7dd7a80b-3b7c-4cb1-ab31-219c6c3ad3c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Remove autogenerated 'id' when using existing database

[Ben in campus]

Django Version: (1, 8, 0, 'final', 0)

Issue: I have an existing database, so I integrated it following the
instruction in https://docs.djangoproject.com/en/1.8/howto/legacy-databases/
to inspectdb and generated models.py. That table does NOT have column 'id',
so the generated models.py doesn't have 'id' either. The model is unmanaged
(managed = False).
But the Django page failed, saying something like 'can not find id column
in the table'. Somehow the query added 'id' in the select fields.


Fixed: Modified
/usr/local/lib/python2.7/dist-packages/django/db/models/options.py
Old: line 284-287
else:
auto = AutoField(verbose_name='ID', primary_key=True,
auto_created=True)
model.add_to_class('id', auto)
New:
else:
if self.managed:
auto = AutoField(verbose_name='ID', primary_key=True,
auto_created=True)
model.add_to_class('id', auto)

That works well for my system. I think it makes sense that Django should
not add AutoField for unmanaged class.

Please confirm and decide whether to patch this into your code base. Thanks.






Ben Lin
http://benincampus.blogspot.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAAqSmN6mFjy6CbOuM2ywM2LsQ-6ryEVvCOakkp2Mw5Wiboj0Jw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: one patch to fix a Django 1.8 issue for merging legacy database

[Marc Tamlyn]

The automatic ID field would not be added if you have a primary key. I'm
not sure if inspectdb does pick up primary keys, I believe it does though.

I feel this discussion may be more suited to django-users, our forum for
helping debugging user issues.

Marc

On 28 April 2015 at 07:48, Ben L  wrote:

> Issue: I have an existing database, so the guide in
> https://docs.djangoproject.com/en/1.8/howto/legacy-databases/ to inspect
> db and created models.py .
>
> That table does NOT have an 'id' column, and the created models.py doesn't
> have 'id' either, and the class is unmanaged (managed=False). But when I
> use Django to create page, the system failed, saying the 'id' is not found
> in the table. Somehow the query included 'id' in the select fields.
>
> After a little bit of digging, I changed
> /usr/local/lib/python2.7/dist-packages/django/db/models/options.py:
> Old:
> line 284-287:
> else:
> auto = AutoField(verbose_name='ID', primary_key=True,
> auto_created=True)
> model.add_to_class('id', auto)
>
> New:
> else:
> if self.managed:
> auto = AutoField(verbose_name='ID', primary_key=True,
> auto_created=True)
> model.add_to_class('id', auto)
>
> Then my class will not get into this "AutoField" action to add 'id' in the
> query.
>
> Looks like an apparent bug. This change works well for me. Please check
> and confirm whether this should be commit into you code base.
>
> Thanks.
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/7dd7a80b-3b7c-4cb1-ab31-219c6c3ad3c5%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1HBgpHwwMQvNOE0GkKK%3D3EQE_jAF7SnUR5nnOJE6%2Bmzeg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Remove autogenerated 'id' when using existing database

[Javier Guerra Giraldez]

On Tue, Apr 28, 2015 at 1:59 AM, Ben in campus  wrote:
> That table does NOT have column 'id', so the generated models.py doesn't
> have 'id' either. The model is unmanaged (managed = False).


if your table has a primary key, add the primary_key=True flag to that
field and Django won't add an 'id' field.

-- 
Javier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFkDaoR_r4CnwE58TVcvFPtcD2PXtzFeVKzzKdnXKVzA0DjafQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: System check is using the default database connection for all the models

[Ion Scerbatiuc]

I'll try to get a PR/proposal to fix the issue as soon as I get some free 
time this week. 

Should I also submit a bug here? https://code.djangoproject.com

Thanks,
Ion

On Saturday, April 25, 2015 at 5:00:02 PM UTC-7, Tim Graham wrote:
>
> It seems like a bug to me. If I had to guess, I'd say it's a 
> multi-database setup that no one thought to test when the system check 
> framework was developed.
>
> On Friday, April 24, 2015 at 3:49:03 PM UTC-4, Ion Scerbatiuc wrote:
>>
>> Hello,
>>
>> Wasn't sure if this is a bug or not, and I couldn't find any related 
>> tickets on https://code.djangoproject.com
>>
>> We have the following database set-up:
>>
>>- the default database is MySQL
>>- two additional databases are PostGIS
>>
>> The system check framework (either `manage.py check` or `manage.py 
>> runserver`) is using the default database (mysql) to validate 
>> `django.contrib.gis.db.models.Model`-based models, and the commands are 
>> blowing up with the following error: 
>> AttributeError: 'DatabaseOperations' object has no attribute 
>> 'geo_db_type'. 
>>
>> You can find the detailed stack trace here: 
>> https://gist.github.com/delinhabit/587d6f26afb4bbc559cb
>>
>> We set-up database routers for the PostGIS models to use the proper 
>> connection, but the check framework seems to ignore them. 
>> Are we doing something wrong? 
>> Is this a known pitfall of the system check framework around multiple 
>> databases that we are unaware of? 
>> Or is this a bug?
>>
>> Thanks,
>> Ion
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a3fad72a-16ed-4bd2-a6e2-acbe2ceffa0d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: System check is using the default database connection for all the models

[Tim Graham]

Yes. Any non-trivial pull request should have a Trac ticket. See also our 
patch review checklist: 
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#patch-review-checklist
.

On Tuesday, April 28, 2015 at 10:40:44 AM UTC-4, Ion Scerbatiuc wrote:
>
> I'll try to get a PR/proposal to fix the issue as soon as I get some free 
> time this week. 
>
> Should I also submit a bug here? https://code.djangoproject.com
>
> Thanks,
> Ion
>
> On Saturday, April 25, 2015 at 5:00:02 PM UTC-7, Tim Graham wrote:
>>
>> It seems like a bug to me. If I had to guess, I'd say it's a 
>> multi-database setup that no one thought to test when the system check 
>> framework was developed.
>>
>> On Friday, April 24, 2015 at 3:49:03 PM UTC-4, Ion Scerbatiuc wrote:
>>>
>>> Hello,
>>>
>>> Wasn't sure if this is a bug or not, and I couldn't find any related 
>>> tickets on https://code.djangoproject.com
>>>
>>> We have the following database set-up:
>>>
>>>- the default database is MySQL
>>>- two additional databases are PostGIS
>>>
>>> The system check framework (either `manage.py check` or `manage.py 
>>> runserver`) is using the default database (mysql) to validate 
>>> `django.contrib.gis.db.models.Model`-based models, and the commands are 
>>> blowing up with the following error: 
>>> AttributeError: 'DatabaseOperations' object has no attribute 
>>> 'geo_db_type'. 
>>>
>>> You can find the detailed stack trace here: 
>>> https://gist.github.com/delinhabit/587d6f26afb4bbc559cb
>>>
>>> We set-up database routers for the PostGIS models to use the proper 
>>> connection, but the check framework seems to ignore them. 
>>> Are we doing something wrong? 
>>> Is this a known pitfall of the system check framework around multiple 
>>> databases that we are unaware of? 
>>> Or is this a bug?
>>>
>>> Thanks,
>>> Ion
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/723616ec-6360-4e13-ac04-f01221b48a3c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Remove autogenerated 'id' when using existing database

[Ben L]

It is true that the table doesn't have a primary key. 

1, I might be able to talk to the DBA to add a primary key in here and re-sync 
the class. But is that required for each table to have pk to run Django?

2, what if I just modify the class to have fake pk =True, but not modify the 
database structure? Is that a common practice?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8d12fb26-9035-49a3-8530-45bdd3dd0777%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Remove autogenerated 'id' when using existing database

[Thorsten Sanders]

I do that since years with tables not having a primary key without 
problems, but I am only using django orm on those to select data.


Am 28.04.2015 17:35, schrieb Ben L:

It is true that the table doesn't have a primary key.

1, I might be able to talk to the DBA to add a primary key in here and re-sync 
the class. But is that required for each table to have pk to run Django?

2, what if I just modify the class to have fake pk =True, but not modify the 
database structure? Is that a common practice?



--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/553FAB08.4090402%40gmx.net.
For more options, visit https://groups.google.com/d/optout.

Translation documentation wrong import

[Mounir Messelmeni]

I've opened a pull request for fixing an import on the translation 
documentation, I just changed ugettext_lazy to ungettext_lazy.

You can check this PR: https://github.com/django/django/pull/4575

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5ae57bf2-7349-4771-b8a9-87de7d9d351c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: one patch to fix a Django 1.8 issue for merging legacy database

[Shai Berger]

Hi Ben,

Thanks for the change you suggested.

On Tuesday 28 April 2015 09:48:26 Ben L wrote:

>[paraphrase] An automatic primary key shouldn't be added to unmanaged models,
>[paraphrase] the current behavior where it is added is a bug

Please have a look at the documentation[1] -- it states clearly that each 
model requires a primary key field. Quite a lot of Django's behavior depends on 
it -- in particular, you cannot save an instance of a model without a primary 
key; of course, you cannot have another model point to it with an FK; etc.

So, the use case supported by your suggested fix -- an isolated table which the 
Django app never updates -- seems to be supported by raw queries; the 
potential for problems created by relaxing the requirement to have a PK, seems 
to outweigh the benefits by far. Thus, I don't think we should accept your 
suggestion.

Perhaps it may seem better to error out more gracefully when faced with 
unmanaged models with no explicit PK. However, that would lead to funny 
results when introspecting a schema which was, in fact, created by Django. 

If I've missed anything, please explain,

Shai.

[1] 
https://docs.djangoproject.com/en/1.8/topics/db/models/#automatic-primary-key-fields

Re: Translation documentation wrong import

[Tim Graham]

Thanks. For future reference, we don't need a message to this list in order 
to know when a pull request is opened.

On Tuesday, April 28, 2015 at 1:16:28 PM UTC-4, Mounir Messelmeni wrote:
>
> I've opened a pull request for fixing an import on the translation 
> documentation, I just changed ugettext_lazy to ungettext_lazy.
>
> You can check this PR: https://github.com/django/django/pull/4575
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a21a4073-b445-46fe-bd44-06d0620596af%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea/request for help: Django Developers Community Survey

[Markus Holtermann]

It's an amazing idea. Thanks for putting it up, Aymeric and Tim!

Can we add a question regarding usage of test frameworks (i.e., unittest2, 
py.test, nose) similar to "Which popular third-party apps do you rely on?" 
For example "Which test frameworks do you use?" - "unittest2, py.test, 
nose, other". That would allow us to see if we should / can include 
features in django.test that may require a specific framework without 
excluding too many people of our community.

/Markus

On Monday, April 27, 2015 at 9:59:24 PM UTC+2, Thorsten Sanders wrote:
>
>  I wrote in that thread too why I dont like such fast releases and at 
> least someone else asked too to give more options on that one question, on 
> the developer mailing list its kinda only some people who are writing not 
> reflecting all the developers such an survey maybe reach more of them and 
> then the answer about such an important question shouldnt be reduced to 3 
> little options a handfull people decided on, that wouldnt reflect what 
> people really want if they cant choose an real answer.
>
> Am 27.04.2015 02:46, schrieb Tim Graham:
>  
> The idea of the release schedule question is to form consensus on the 
> options that have already been proposed in the "1.9 release planning 
> " 
> thread. If you have a different idea, please propose it there.
>
> On Sunday, April 26, 2015 at 6:53:14 AM UTC-4, Thorsten Sanders wrote: 
>>
>>  I like the idea of an survey, but find the release question with only 3 
>> options quite limited, how about to allow there to put own numbers instead 
>> of giving fixed answers or at least an other field?
>>
>> Am 25.04.2015 14:29, schrieb Tim Graham:
>>  
>> Aymeric and I put together a draft:
>>
>>
>> https://docs.google.com/forms/d/1Owv-Y_beohyCm9o2xPamdBnvjreNYoWai3rDloKZxWw/viewform
>>
>> All questions are optional so you can just click through it to view the 
>> questions. We'll probably clear any responses before its finalized anyway.
>>
>> Let us know if you think we should make any additions or changes.
>>
>> On Wednesday, April 22, 2015 at 4:03:44 AM UTC-4, Federico Capoano wrote: 
>>>
>>> Great idea. 
>>> The questions look good enough to me.
>>>
>>>  I love django-apps or libraries shipped in python packages. One of the 
>>> reason I love Django is the fact that it didn't frenetically add stuff to 
>>> the framework just because it's cool.
>>> The good thing of python packages is that you can get some data from 
>>> pypi (downloads) and github (clones). But we can't do that with contrib 
>>> apps unfortunately.
>>>
>>>  Federico
>>>
>>>
>>> On Saturday, April 18, 2015 at 1:00:13 AM UTC+2, Tim Graham wrote: 

 I had an idea to conduct a survey to get a sense of how developers are 
 using Django. I first had the idea when the question of maintenance of the 
 Oracle GIS backend came up. We really have no idea whether or not anyone 
 is 
 actually using that backend, and it would be helpful to know so we are not 
 wasting resources on unused features. Also there's the question of how 
 often to release Django. I think it would be nice to make that decision 
 based on some data from the community.

 Is anyone is interested in coordinating such a survey (collating 
 questions, preparing the online survey, etc.).

 Some question ideas to get started:

 Which database backend(s) do you use?
 [ ] Checkbox for each one

 Which contrib apps do you use?
 [ ] Checkbox for each one

 How often would you like to see new major version of Django released?
 [ ] List some options, probably between 6 and 9 months.

 Describe which version of Django you use (check all the apply):
 [ ] I only use long-term support releases.
 [ ] I upgrade to the latest stable version as quickly as possible.
 [ ] I run off of master.
 [ ] I upgrade Django when the version I am using is nearing the end of 
 its support (or after).
 [ ] I don't bother upgrading Django, even if it becomes unsupported.
  
>>>   -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com.
>> To post to this group, send email to django-d...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/f14071d1-c570-483a-abd2-833e1b47ab4d%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>   -- 
> You received this message because you are s