Re: Django OperationalError

[Petar Pilipovic]

Hello James, will do but I am not at mine lap top atm, gona do it as soon
as posible, tank you very much.

On Saturday, February 28, 2015, James Schneider 
wrote:
> Generally this happens when you don't apply the initial migration. Have
you run 'python manage.py migrate' (assuming Django >= 1.7 since you
mentioned making migrations) and if you have, what was the output? If you
aren't sure, run it again as it shouldn't hurt anything.
>
> Check your database and make sure that the tables actually exist. If not,
and there is no production data (assuming not based on the question), drop
and recreate the DB to clear out any previously failed migration attempts
and apply your migrations again using the command I specified. Capture the
entire output of the command and paste it back to this list so that we can
help more.
>
> -James
>
> On Feb 27, 2015 10:02 PM, "Petar Pilipovic"  wrote:
>>
>> Hello, I have manage to merge mine application to pythonanywhere.com.
After I have done all the needed installing, uploading files, collecting
static, making migrations to mine django application, I have experienced an
OperationError saying:
>>
>> no such table: django_session
>> You can find the rest of mine question here on stackoverflow, Can
someone help me over come this error, tank you.
>>
>>
>> --
>> You received this message because you are subscribed to the Google
Groups "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send
an email to django-users+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-users@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/01f5c13c-5b7e-40ea-b98b-e37640e477df%40googlegroups.com
.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to a topic in the
Google Groups "Django users" group.
> To unsubscribe from this topic, visit
https://groups.google.com/d/topic/django-users/MOsaEEDNyQg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/CA%2Be%2BciXfPuqKgQz89CVgaB07cf_Lwj%3DK-XcdtV9GK1EZ%3DQxMaQ%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAK8niQsiLMaeLE%3D_8phdGhKqsYXuuL3nwStTJwXJQ%3D%2BrVuNYLQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django OperationalError

[James Schneider]

Generally this happens when you don't apply the initial migration. Have you
run 'python manage.py migrate' (assuming Django >= 1.7 since you mentioned
making migrations) and if you have, what was the output? If you aren't
sure, run it again as it shouldn't hurt anything.

Check your database and make sure that the tables actually exist. If not,
and there is no production data (assuming not based on the question), drop
and recreate the DB to clear out any previously failed migration attempts
and apply your migrations again using the command I specified. Capture the
entire output of the command and paste it back to this list so that we can
help more.

-James
On Feb 27, 2015 10:02 PM, "Petar Pilipovic"  wrote:

> Hello, I have manage to merge mine application to pythonanywhere.com.
> After I have done all the needed installing, uploading files, collecting
> static, making migrations to mine django application, I have experienced an
> OperationError saying:
> no such table: django_session
>
> You can find the rest of mine question here on stackoverflow
> ,
> Can someone help me over come this error, tank you.
>
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/01f5c13c-5b7e-40ea-b98b-e37640e477df%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CA%2Be%2BciXfPuqKgQz89CVgaB07cf_Lwj%3DK-XcdtV9GK1EZ%3DQxMaQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Django OperationalError

[Petar Pilipovic]

Hello, I have manage to merge mine application to pythonanywhere.com. After 
I have done all the needed installing, uploading files, collecting static, 
making migrations to mine django application, I have experienced an 
OperationError saying:
no such table: django_session

You can find the rest of mine question here on stackoverflow 
, Can 
someone help me over come this error, tank you.
 


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/01f5c13c-5b7e-40ea-b98b-e37640e477df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migrations force me to have, forever, any name/reference I use in field validators=, choices=, whatever, valid forever (even if the requirements change).

[Gergely Polonkai]

Hello,

another solution may be to patch your models in the migration module or
class, like:

import myapp.models

myapp.models.valid_identifier = something_acceptable()

Although it seems a bit ugly, I just tested it, and it works. This way
valid_identifier will live during the migration only.

Best,
Gergely
On 27 Feb 2015 21:17, "Luis Masuelli"  wrote:

> Thanks :D Did not think about squashing migrations as solution for this
> problem! But it does the job.
> OTOH the fact about historical models has nothing to do with my problem
> (since it is not related at all with instancing a model, but just about the
> definition and not getting a NameError).
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/15bb8a96-18a5-432c-afeb-7a3299ca7a4d%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CACczBUJz9A%2ByKxTkP-prtfXihoSudM6V0HLD_mXUZTu2yQqjkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Model field with default value and choices is always reported as changed, even if unchanged

[Carsten Fuchs]

Am 26.02.2015 um 19:06 schrieb Carsten Fuchs:

The expected output is `False`,[...]


Just for future reference, this is continued here:
https://code.djangoproject.com/ticket/24428

Best regards,
Carsten

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

Re: Migrations force me to have, forever, any name/reference I use in field validators=, choices=, whatever, valid forever (even if the requirements change).

[Luis Masuelli]

Thanks :D Did not think about squashing migrations as solution for this 
problem! But it does the job.
OTOH the fact about historical models has nothing to do with my problem 
(since it is not related at all with instancing a model, but just about the 
definition and not getting a NameError).

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/15bb8a96-18a5-432c-afeb-7a3299ca7a4d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Did you try NamedUrlWizardView ? I tried example code but does not work ;-(

[Mike]

File ... ... site-packages\django\views}generic\base.py line 60 
"attributes of the class." % <(cld.__nsmr__,key)
TypeError: ApplyWizard() received an invalid keyword 'url_name'.
as_view only accepts arguments that are already attributes of the class.

If somebody got NamedUrlWizardView working, let me know how

-Thanks


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/6abc9c4f-e6b5-4ef5-8fab-e75c326b45aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: djangoproject.com https access problems

[James Schneider]

The proxy is likely forcing a TLS fallback in a way that Firefox doesn't
like. Ensure you are using the latest version of FF, but even then, unless
you have control off the proxy, there may not be much you can do except
open a support ticket with your IT department.

https://bugzilla.mozilla.org/show_bug.cgi?id=1072382

-James
On Feb 27, 2015 8:58 AM, "anton"  wrote:

> Hi,
>
> at home it works, but in my company
> the proxy refuses the connection to:
>
> https://www.djangoproject.com
>
> and my firefox gives me an error:
>
> ssl_error_inappropriate_fallback_alert
>
> Question: since when did you switch the website to https
> (or didn't I notice it)
>
> Other sites seems to work, is there anything special
> with https://www.djangoproject.com ?
>
> All the time I had no problems.
>
>
> Anton
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/mcq7ng%24s55%241%40ger.gmane.org
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

djangoproject.com https access problems

[anton]

Hi,

at home it works, but in my company
the proxy refuses the connection to:

https://www.djangoproject.com

and my firefox gives me an error:

ssl_error_inappropriate_fallback_alert

Question: since when did you switch the website to https
(or didn't I notice it)

Other sites seems to work, is there anything special
with https://www.djangoproject.com ?

All the time I had no problems.


Anton

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/mcq7ng%24s55%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: Research: Translations od documentation

[Kelvin Nyota]

I thought there was a plugin for that? You can also do some research 
 and find some articles on how to 
implement it.

On Thursday, 26 February 2015 05:11:21 UTC-5, Tomáš Ehrlich wrote:
>
> Hello, 
> tonight is regular python/ruby meetup in Brno (Czech republic) about 
> documentation. Last few months I’ve been working on project concerning 
> localization of documents. I would like to know your opinion about 
> localization of documentation: 
>
> Do you think it would be useful to translate documentation of: 
> 1) Django 
> 2) Python 
> 3) Any project documented using Sphinx (like numpy, scipy, request, …) 
>
> Three simple answers Yes/No would help me a lot. If you write a short 
> paragraph about your opinion, I will very appreciate it. 
>
> Thank you 
>
>
> Cheers, 
>Tom 
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/be5c9914-9c0c-47f0-b88a-3c143d5d39ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can the new `Prefetch` solve my problem?

[James Schneider]

On Feb 27, 2015 12:51 AM, "aRkadeFR"  wrote:
>
> Yeah, but from my experience, your example through a new
> query. You have to (and please correct me if I'm wrong or
> there are other ways) use the self.chair_set.all() in order
> to not through a new query when you have prefetched the
> chairs.

AFAIK, self.chair_set.all() would always spawn a second query unless
something like select_related() had been used previously to cache that
query result

I provided several examples, some of which spawn a second query (and may be
appropriate, I can't provide an affirmative answer for the OP without
knowing how many queries are being run per page load and average query
time, etc.). You'll need to be more specific.

I think I accidentally referred to some of the model fields as if they were
FK's, but they probably should have had .all() after all of the references
since everything was an M2M relationship.

>
> To be simple and answer the problem: my only solution I
> have in mind is to prefetched all the objects (chairs), and
> then filter it in python with properties like I said. But as you
> said it will load too much objects...

I think there was some miscommunication here. The OP stated that loading
all of the chairs was infeasible, and I would tend to agree.

My only clarification would be that loading all of the chairs via something
like Chair.objects.all() would be a bad idea, since you have no idea how
many chairs you may have in the entire database.

Loading >10k Chair objects into memory and having Django coerce those into
model objects, and then performing post processing in some custom app code
to filter that list back down to something reasonable will give you a bad
time, every time. Your users will be unhappy with pages that take seconds
to load, and your server processes will be unhappy assuming you have plenty
of RAM/CPU to handle such a request. Now multiply that load by X number of
users...and you're quickly hitting CPU and process limits for RAM
allocation.

However, "loading all of the chairs" via a M2M or FK relationship such as
desk_obj.nearby_chairs.all() (assuming the OP reconfigured the model fields
as I suggested before, or even using the existing Chair M2M to Desk) would
likely be perfectly valid and would probably be a small subset of the total
chairs in the system (or maybe None or all of them).

>
> Still watching the thread cause I have couple of problems
> like this one :)
>

I don't necessarily run in to this specific problem, so I'm not sure how
much more I can contribute. A lot of the model changes I suggested were
educated guesses and may not be valid at all given other requirements or
design considerations in the project.

> aRkadeFR
>
>
> On 02/26/2015 08:27 PM, James Schneider wrote:
>>
>> Heh, I just realized that aRkadeFR had replied with a similar idea to
use a property. At least I know I'm not too far off on my thinking. :-D
>>
>> -James
>>
>> On Thu, Feb 26, 2015 at 11:02 AM, James Schneider <
jrschneide...@gmail.com> wrote:
>>>
>>> Whoops, accidentally sent that last one too early, here's the
continuation:
>>>
>>> However, that probably doesn't buy you much since you are still doing
an extra query for every Desk you pull from your original query.
>>>
>>> Funny enough, I was googling around for an answer here, and stumbled
across this:
>>>
>>>
https://docs.djangoproject.com/en/1.7/ref/models/queries/#django.db.models.Prefetch
>>>
>>> which I think is what you were referring to initially in your OP. I
wasn't even aware of its existence. Prefetch() is a helper class for
prefetch_related(). Taking a quick glance through the source code, I would
imagine that it probably won't help you much, since the functionality of
that class only controls the action of prefetch_related().
>>>
>>>
>>> Zooming out a bit, the crux of your problem is this: An attribute you
wish to populate is not an FK or M2M field, it is an entirely separate
Queryset with some moderately complex filters. The built-in ORM
functionality for pre-loading via prefetch/select_related() is expecting a
FK or M2M relationship and can't  use another queryset AFAIK. The
high-level functionality of prefetch_related() is probably close to what
you want, which is to run a single second query to collect all of
the favorite_or_nearby_chairs for all of the Desks in your original query,
and then glue everything together behind the scenes in Python to make the
desk_obj.favorite_or_nearby_chairs available seamlessly.
>>>
>>> I would then wonder if there is another way to organize this data to
make it easier to work with? How about adding a 'favorite_chairs' field to
the Desk model that has an M2M to Chair? I would also update your
'nearby_desks' model field to use 'nearby_chairs' as the related_field.
>>>
>>> Then you could do something like the following:
>>>
>>> desks = Desk.objects.filter().select_related('nearby_chairs', 'favorite_chairs')
>>>
>>> Then, you can modify your model with a property that will 

Re: Can the new `Prefetch` solve my problem?

[aRkadeFR]

Yeah, but from my experience, your example through a new
query. You have to (and please correct me if I'm wrong or
there are other ways) use the self.chair_set.all() in order
to not through a new query when you have prefetched the
chairs.

To be simple and answer the problem: my only solution I
have in mind is to prefetched all the objects (chairs), and
then filter it in python with properties like I said. But as you
said it will load too much objects...

Still watching the thread cause I have couple of problems
like this one :)

aRkadeFR

On 02/26/2015 08:27 PM, James Schneider wrote:
Heh, I just realized that aRkadeFR had replied with a similar idea to 
use a property. At least I know I'm not too far off on my thinking. :-D


-James

On Thu, Feb 26, 2015 at 11:02 AM, James Schneider 
> wrote:


Whoops, accidentally sent that last one too early, here's the
continuation:

However, that probably doesn't buy you much since you are still
doing an extra query for every Desk you pull from your original query.

Funny enough, I was googling around for an answer here, and
stumbled across this:


https://docs.djangoproject.com/en/1.7/ref/models/queries/#django.db.models.Prefetch

which I think is what you were referring to initially in your OP.
I wasn't even aware of its existence. Prefetch() is a helper class
for prefetch_related(). Taking a quick glance through the source
code, I would imagine that it probably won't help you much, since
the functionality of that class only controls the action of
prefetch_related().


Zooming out a bit, the crux of your problem is this: An attribute
you wish to populate is not an FK or M2M field, it is an entirely
separate Queryset with some moderately complex filters. The
built-in ORM functionality for pre-loading via
prefetch/select_related() is expecting a FK or M2M relationship
and can't  use another queryset AFAIK. The high-level
functionality of prefetch_related() is probably close to what you
want, which is to run a single second query to collect all of
the favorite_or_nearby_chairs for all of the Desks in your
original query, and then glue everything together behind the
scenes in Python to make the desk_obj.favorite_or_nearby_chairs
available seamlessly.

I would then wonder if there is another way to organize this data
to make it easier to work with? How about adding a
'favorite_chairs' field to the Desk model that has an M2M to
Chair? I would also update your 'nearby_desks' model field to use
'nearby_chairs' as the related_field.

Then you could do something like the following:

desks = Desk.objects.filter().select_related('nearby_chairs', 'favorite_chairs')

Then, you can modify your model with a property that will return
the concatenation of nearby_chairs and favorite_chairs:

class Desk(models.Model):
@property
def favorite_or_nearby_chairs(self):
return self.nearby_chairs.all() + self.favorite_chairs

I don't believe this will spawn another query, since
select_related() will have already run and have the results
cached. You may also want to consider moving 'nearby_desks' out of
Chair and renaming it to 'nearby_chairs' in Desk, and using a
related_name of 'nearby_desks' instead. Then you can remove the
.all() from the property definition from above and it definitely
won't spawn a query. Obviously you'll need to create other
processes that will populate desk.favorite_chairs, which may or
may not be feasible.

TL;DR; I don't believe you can pre-fetch anything because of the
extra SQL logic needed to calculate the favorite_or_nearby_chairs
attribute. It might be possible via raw SQL though. Reformatting
your data models may lead to an easier time since you can then
take advantage of the some of the optimizations Django offers.

I'm slightly out in right field on this one, so YMMV, but taking a
hard look at the current model design would be where I would start
to try and eliminate the need for that custom queryset.

Again, the django-debug-toolbar is your friend in these cases, but
obviously a high number of even relatively fast queries can have a
detrimental effect on your load times. Also ensure that the fields
you are using to filter contain indexes, if appropriate/available.

-James




On Thu, Feb 26, 2015 at 10:17 AM, James Schneider
> wrote:

Yep, looks like I misunderstood.

So, you want to have something like this pseudo code:

desks = Desk.objects.filter()
for desk in desks:
print desk.favorite_or_nearby_chairs

And have favorite_or_nearby_chairs be pre-populated with your
Chair queryset mentioned earlier?

Due to the