Re: manage.py test and uninstalled apps

[Claude Paroz]

Hello Aymeric,

To be clear, I don't contest in any way that design choice. I understand 
and approve it.
I'm just pointing to this unwanted side-effect, wondering if anyone has 
ideas how to circumvent it, as I think it's a legitimate use case.
I'm also aware that we have not much control over test discovery and 
importing process.

The workaround for me will probably to write a custom test management 
command to define test labels dynamically based on current settings.

Claude

On Wednesday, November 18, 2015 at 9:29:08 PM UTC+1, Aymeric Augustin wrote:
>
> Hello Claude,
>
> Generally speaking, you cannot safely use a model that isn't defined in an 
> application that is in INSTALLED_APPS. Django raises a warning when you 
> import such a model.
>
> This restriction prevents situations where relations between models aren't 
> set up correctly. There’s a string of such bugs in Trac. I discussed this 
> in my DjangoCon Europe 2014 talk.
>
> Best regards,
>
> -- 
> Aymeric.
>
>
>
> On 18 nov. 2015, at 21:04, Claude Paroz  
> wrote:
>
> Hello,
>
> I have a Django project with different apps and settings. Let's say 
> settings A have A in INSTALLED_APPS but not B, and settings B have B in 
> INSTALLED_APPS but not A. Note also that I cannot have both apps installed, 
> for some reason.
> In that configuration and from Django 1.9, ./manage.py test will always 
> fail with the message :
> RuntimeError: Model class  doesn't declare an 
> explicit app_label and either isn't in an application in INSTALLED_APPS or 
> else was imported before its application was loaded.
>
> Do we admit that for such type of projects, you always have to specify 
> your app labels starting from Django 1.9?
> Or did I miss some hidden trick to avoid that?
>
> Claude
>
>
>
> -- 
> 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/b7d021c5-bc44-48e6-8441-b57a40758c53%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/6181711b-1ec2-4fbe-a4c1-29e5bbac8fa5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Question] Many-To-Many query where only pk is returned

[Josh Smeaton]

It might be a bit early in the day for me, but isn't that query already 
optimised? That is, it's already eliminated a join. It hasn't joined to the 
"Especialidad" table, it's only joined to the intermediate table. I *think* 
the join to the intermediate table is necessary because there could be 
duplicates.

Given the tables:

Usuario(pk):
1
2

Intermediate(usurario_id, especialidad_id):
1, 1
1, 2

Especialidad(pk)
1
2

Joining Usuario to Intermediate will return 4 results in SQL (2 for each pk 
on Usuario) unless there was a distinct in there somewhere. I haven't 
tested, so I'm not sure if django does duplicate elimination, but I'm 
pretty sure it doesn't.

Does this look right to you, or am I missing something?

Cheers


On Thursday, 19 November 2015 11:41:22 UTC+11, Cristiano Coelho wrote:
>
> Hello there,
>
> Lets say I have these two models (sorry about the spanish names!) ( Django 
> 1.8.6 and MySQL backend )
>
> class Especialidad(models.Model):
> nombre = models.CharField(max_length=250, blank=False, unique=True)
>
>
>
> class Usuario(AbstractBaseUser): 
> permisosEspecialidad = models.ManyToManyField("Especialidad", blank=True)
>
> Let u be some Usuario instance, and the following query:
>
> u.permisosEspecialidad.all().values_list('pk',flat=True)
>
> The actual printed query is:
>
> SELECT `samiBackend_especialidad`.`id`
> FROM `samiBackend_especialidad` 
>   INNER JOIN `samiBackend_usuario_permisosEspecialidad` ON ( 
> `samiBackend_especialidad`.`id` = 
> `samiBackend_usuario_permisosEspecialidad`.`especialidad_id` ) 
> WHERE `samiBackend_usuario_permisosEspecialidad`.`usuario_id` = 8
>
> As my understanding, since I'm only selecting the id field which is already 
> present in the intermediary table (and is also a FK), the actual join is 
> redundant, as I have all the info I need in this case.
>
> So the query could work like this
>
> SELECT `samiBackend_usuario_permisosEspecialidad`.`especialidad_id`
> FROM  `samiBackend_usuario_permisosEspecialidad`
> WHERE `samiBackend_usuario_permisosEspecialidad`.`usuario_id` = 8
>
>
> I guess this works this way because this particular case might be hard to 
> detect or won't be compatible with any additional query building, however, 
> for ForeignKey relations, this optimization is already done (If you select 
> the primary key from the selected model only, it wont add a join)
>
> What would be the complications to implement this? Would it worth the effort?
>
>
>

-- 
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/9eddc20d-8740-48d1-a38d-fd7a00a56f2a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature proposal: selection of views and tables for inspectdb

[Tim Graham]

One correction, inspectdb doesn't currently create models for views, but 
this isn't the first time that code caused confusion, see 
https://code.djangoproject.com/ticket/25038.

I agree that fixing the inspect SQL would be the ideal solution. José, I 
didn't follow the conversation closely enough to tell if you presented a 
reason this infeasible for some reason? I'd rather not add more complexity 
(arguments to inspectdb) where an easy solution already exists (removing 
unwanted models from the generated output). 

On Wednesday, November 11, 2015 at 7:40:49 AM UTC-5, Jani Tiainen wrote:
>
> Hi,
>
> I guess it's just about crafting proper SQL for Oracle to do proper 
> introspection and do a PR to be inline with other backends what comes to 
> table/view discovery.
>
> On 11.11.2015 14:14, José Tomás Tocino wrote:
>
> So... is this going anywhere?
>
> El lunes, 9 de noviembre de 2015, 17:55:36 (UTC+1), José Tomás Tocino 
> escribió: 
>>
>> Well maybe extending queries to do that. Wonder is there similiar issues 
>>> with postgresql?
>>>
>>
>> Nope, I've just tried granting SELECT access to a user and he can inspect 
>> the tables properly (in postgresql):
>>
>> postgres=# CREATE DATABASE permissions;
>> CREATE DATABASE
>> postgres=# \c permissions;
>> You are now connected to database "permissions" as user "postgres".
>> permissions=# create table foo (id int, name varchar(255));
>> CREATE TABLE
>> permissions=# GRANT CONNECT ON DATABASE permissions to tester;
>> GRANT
>> permissions=# GRANT USAGE ON SCHEMA public TO tester;
>> GRANT
>> permissions=# GRANT SELECT ON foo TO tester;
>> GRANT
>> permissions=# \q
>> (ENV)vagrant@vagrant-ubuntu-trusty-64:~$ ./manage.py inspectdb
>> # This is an auto-generated Django model module.
>> # You'll have to do the following manually to clean this up:
>> #   * Rearrange models' order
>> #   * Make sure each model has one field with primary_key=True
>> #   * Remove `managed = False` lines if you wish to allow Django to 
>> create, modify, and delete the table
>> # Feel free to rename the models, but don't rename db_table values or 
>> field names.
>> #
>> # Also note: You'll have to insert the output of 'django-admin sqlcustom 
>> [app_label]'
>> # into your database.
>> from __future__ import unicode_literals
>>
>> from django.db import models
>>
>>
>> class Foo(models.Model):
>> id = models.IntegerField(blank=True, null=True)
>> name = models.CharField(max_length=255, blank=True, null=True)
>>
>> class Meta:
>> managed = False
>> db_table = 'foo'
>>
>>
>> So there's that
>>  
>>
>>>
>>> -- 
>>> José Tomás Tocino García
>>> http://www.josetomastocino.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-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/CAAOwDo7J33ScxGvQ3UZe2HLMLbc1Eim1TPGwqFDap6Xdp%2BJkFw%40mail.gmail.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-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/9acc3506-6585-4dd6-9463-0d431707e441%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/e05f5eb6-b61c-4f24-b584-ad6af18c015e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Question] Many-To-Many query where only pk is returned

[Cristiano Coelho]

Hello there,

Lets say I have these two models (sorry about the spanish names!) ( Django 
1.8.6 and MySQL backend )

class Especialidad(models.Model):
nombre = models.CharField(max_length=250, blank=False, unique=True)



class Usuario(AbstractBaseUser): 
permisosEspecialidad = models.ManyToManyField("Especialidad", blank=True)

Let u be some Usuario instance, and the following query:

u.permisosEspecialidad.all().values_list('pk',flat=True)

The actual printed query is:

SELECT `samiBackend_especialidad`.`id`
FROM `samiBackend_especialidad` 
INNER JOIN `samiBackend_usuario_permisosEspecialidad` ON ( 
`samiBackend_especialidad`.`id` = 
`samiBackend_usuario_permisosEspecialidad`.`especialidad_id` ) 
WHERE `samiBackend_usuario_permisosEspecialidad`.`usuario_id` = 8

As my understanding, since I'm only selecting the id field which is already 
present in the intermediary table (and is also a FK), the actual join is 
redundant, as I have all the info I need in this case.

So the query could work like this

SELECT `samiBackend_usuario_permisosEspecialidad`.`especialidad_id`
FROM  `samiBackend_usuario_permisosEspecialidad`
WHERE `samiBackend_usuario_permisosEspecialidad`.`usuario_id` = 8


I guess this works this way because this particular case might be hard to 
detect or won't be compatible with any additional query building, however, for 
ForeignKey relations, this optimization is already done (If you select the 
primary key from the selected model only, it wont add a join)

What would be the complications to implement this? Would it worth the effort?


-- 
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/d31fdc22-8105-4be3-8c99-bc01279c4e5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: manage.py test and uninstalled apps

[Aymeric Augustin]

Hello Claude,

Generally speaking, you cannot safely use a model that isn't defined in an 
application that is in INSTALLED_APPS. Django raises a warning when you import 
such a model.

This restriction prevents situations where relations between models aren't set 
up correctly. There’s a string of such bugs in Trac. I discussed this in my 
DjangoCon Europe 2014 talk.

Best regards,

-- 
Aymeric.



> On 18 nov. 2015, at 21:04, Claude Paroz  wrote:
> 
> Hello,
> 
> I have a Django project with different apps and settings. Let's say settings 
> A have A in INSTALLED_APPS but not B, and settings B have B in INSTALLED_APPS 
> but not A. Note also that I cannot have both apps installed, for some reason.
> In that configuration and from Django 1.9, ./manage.py test will always fail 
> with the message :
> RuntimeError: Model class  doesn't declare an 
> explicit app_label and either isn't in an application in INSTALLED_APPS or 
> else was imported before its application was loaded.
> 
> Do we admit that for such type of projects, you always have to specify your 
> app labels starting from Django 1.9?
> Or did I miss some hidden trick to avoid that?
> 
> Claude
> 
> 
> 
> -- 
> 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/b7d021c5-bc44-48e6-8441-b57a40758c53%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/EE28FB5F-A248-41E1-8248-E56DB5E540F2%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

manage.py test and uninstalled apps

[Claude Paroz]

Hello,

I have a Django project with different apps and settings. Let's say 
settings A have A in INSTALLED_APPS but not B, and settings B have B in 
INSTALLED_APPS but not A. Note also that I cannot have both apps installed, 
for some reason.
In that configuration and from Django 1.9, ./manage.py test will always 
fail with the message :
RuntimeError: Model class  doesn't declare an 
explicit app_label and either isn't in an application in INSTALLED_APPS or 
else was imported before its application was loaded.

Do we admit that for such type of projects, you always have to specify your 
app labels starting from Django 1.9?
Or did I miss some hidden trick to avoid that?

Claude


-- 
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/b7d021c5-bc44-48e6-8441-b57a40758c53%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django.utils.version.get_version() discrepancy for Python 2 vs. Python 3

[Aymeric Augustin]

Considering the information provided by Donald, it’s pretty clear to me that we 
should switch to rc as proposed by Tim.

-- 
Aymeric.



> On 18 nov. 2015, at 01:26, Tim Graham  wrote:
> 
> Thanks Donald, updating setuptools was the factor I missed, not Python 2 vs. 
> 3.
> 
> On Tuesday, November 17, 2015 at 5:06:59 PM UTC-5, Donald Stufft wrote:
> 
>> On Nov 17, 2015, at 12:00 PM, Tim Graham  
>> wrote:
>> 
>> There was a small hiccup with the 1.9 release candidate yesterday. Unless 
>> there is some other conflating factor that I missed, generating release 
>> packages using Python 2 will yield a name like "Django-1.9c1.tar.gz" while 
>> Python 3 yields "Django-1.9rc1.tar.gz" ('rc' instead of 'c'). Yesterday's 
>> release must have been the first release candidate to be generated using 
>> Python 3, and this broke the download page because 
>> django.utils.version.get_version() (which the website uses) returns "c1" for 
>> the file name instead of "rc1". I put in a (perhaps temporary) fix to 
>> correct this: https://github.com/django/djangoproject.com/pull/547 
>> 
>> 
>> Do you think it's correct to make the change in Django itself? 
>> https://github.com/django/django/pull/5676 
>>  -- I didn't track down the 
>> reason why this changed in Python.
>> While get_version() isn't a public API, it's widely used according to GitHub 
>> search.
>> 
> 
> Whoever generated the tarballs is probably using a version of setuptools 
> older than 8.0 in their Python 2 environment and a version of setuptools 
> newer than 8.0 in their Python 3 environment.
> 
> 
> -
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
> 
> 
> -- 
> 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/e02a697f-36c4-4604-b484-1907919a6a54%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/72652A2A-292E-4303-ACCE-8BB1104196B0%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.