Re: Dynamically adding a field to a model - via contribute_to_class

[Melvyn Sopacua]

If I may suggest a better approach:

- Make the code as ImageField does (see it's width_field and height_field)
- Then focus on writing the migration for this field

Unfortunately, I don't see a way for custom fields to provide hints to
the migrations framework. So a field that automatically creates
another field is hard to deal with.

Another different approach is to use a custom ForeignKey [1]. Then you
create only one field, but at the cost of a join.

[1] 
https://github.com/furious-luke/django-address/blob/master/address/models.py#L289

On Wed, Sep 13, 2017 at 2:05 PM, Michal Petrucha
 wrote:
> On Tue, Sep 12, 2017 at 12:34:26AM -0700, gernot.c...@gmail.com wrote:
>> Hi,
>>
>> I don't know if crossposting with stackoverflow is allowed here but
>> essentially my problem is explained
>> in 
>> https://stackoverflow.com/questions/46162104/django-dynamic-model-fields-and-migrations.
>> What I want to create is a custom ModelField of type DecimalField, that
>> dynamically adds another ModelField (CharField) to the source model. As far
>> as I can tell, this is nicely explained
>> in 
>> https://blog.elsdoerfer.name/2008/01/08/fuzzydates-or-one-django-model-field-multiple-database-columns/.
>>
>> Let's assume I start with a fresh project and app and add this code to
>> models.py:
>>
>> from django.db import models
>> from django.db.models import signals
>>
>>
>> _currency_field_name = lambda name: '{}_extension'.format(name)
>>
>>
>> class PriceField(models.DecimalField):
>>
>> def contribute_to_class(self, cls, name):
>> # add the extra currency field (CharField) to the class
>> if not cls._meta.abstract:
>> currency_field = models.CharField(
>> max_length=3,
>> editable=False,
>> null=True,
>> blank=True
>> )
>> cls.add_to_class(_currency_field_name(name), currency_field)
>> # add the original price field (DecimalField) to the class
>> super().contribute_to_class(cls, name)
>>
>> # TODO: set the descriptor
>> # setattr(cls, self.name, FooDescriptor(self))
>>
>>
>> class FooModel(models.Model):
>>
>> price = PriceField('agrh', decimal_places=3, max_digits=10, 
>> blank=True, null=True)
>>
>>
>> If I then call *./manage.py makemigrations* the following migration file
>> for the app is created:
>>
>> # Generated by Django 1.11.4 on 2017-09-11 18:02
>> from __future__ import unicode_literals
>>
>> from django.db import migrations, models
>> import testing.models
>>
>>
>> class Migration(migrations.Migration):
>>
>> initial = True
>>
>> dependencies = [
>> ]
>>
>> operations = [
>> migrations.CreateModel(
>> name='FooModel',
>> fields=[
>> ('id', models.AutoField(auto_created=True, primary_key=True, 
>> serialize=False, verbose_name='ID')),
>> ('price', testing.models.PriceField(blank=True, 
>> decimal_places=3, max_digits=10, null=True, verbose_name='agrh')),
>> ('price_extension', models.CharField(blank=True, 
>> editable=False, max_length=3, null=True)),
>> ],
>> ),
>> ]
>>
>>
>> All good, as far as I can tell. The problem comes up if I then call 
>> *./manage.py
>> migrate* which errors with the following exception:
>>
>> ./manage.py migrate testing
>> Operations to perform:
>>   Apply all migrations: testing
>> Running migrations:
>>   Applying testing.0001_initial...Traceback (most recent call last):
>>   File 
>> "/usr/local/var/pyenv/versions/stockmanagement-3.6.2/lib/python3.6/site-packages/django/db/backends/utils.py",
>>  line 63, in execute
>> return self.cursor.execute(sql)
>>   File 
>> "/usr/local/var/pyenv/versions/stockmanagement-3.6.2/lib/python3.6/site-packages/django/db/backends/sqlite3/base.py",
>>  line 326, in execute
>> return Database.Cursor.execute(self, query)
>> sqlite3.OperationalError: duplicate column name: price_extension
>>
> [...]
>> As said, I have a fresh project with no exisiting DB and tables so far. Why
>> is it complaining that there allready exista a column named
>> "price_extension"?. The migration file only contains one field called
>> "price_extension"?
>
> I'm not quite certain about this, but I believe that when the
> migration runner reconstructs a version of your FooModel, it iterates
> over the list of fields, and adds each of them to the reconstructed
> model class one by one. So what happens is that your custom PriceField
> gets added, which in turn creates its price_extension field, and then
> next thing, the migration runner adds the price_extension field one
> more time. So you end up with two instances of the price_extension
> field on the same model, and when eventually the create_model schema
> operation is executed, it adds each of them as another column to the
> table, which is obviously wrong.
>
> As for what you could do to avoid 

Re: More bizarre URL behaviour after deploying

[Antonis Christofides]

That particular issue may be a lighttpd issue, but my question is more general.
Unfortunately I don't remember the kind of trouble I was having with uwsgi.

Are there any people who have used both uwsgi and gunicorn and have a preference
for the former? What benefits have they seen?

Antonis Christofides
http://djangodeployment.com


On 2017-09-13 18:36, Melvyn Sopacua wrote:
> You're missing the fact that it's the scgi module of lighttpd is what
> is causing it. uwsgi shouldn't fix it, as it has no idea if this is
> intentional, for example when using mounts [1].
> As can be seen in the WSGI spec, the WSGI client (uwsgi / gunicorn /
> whathaveyou) should trust what is provided here [2]. If gunicorn does
> it differently, it will prevent you from mounting an app in a virtual
> location, say "/django/".
>
> [1] 
> http://uwsgi-docs.readthedocs.io/en/latest/Nginx.html#hosting-multiple-apps-in-the-same-process-aka-managing-script-name-and-path-info
> [2] https://www.python.org/dev/peps/pep-0333/#environ-variables
>
> On Wed, Sep 13, 2017 at 5:27 PM, Antonis Christofides
>  wrote:
>> Alas it's a tad complicated and I'll try and publish a module with the fix
>> some time soon (it relates to lighttpd, uwsgi, django interactions and the
>> management of SCRIPT_NAME and PATH_INFO environment variables which lighttpd
>> doesn't do to Django's satisfaction and so it needs tweaking and I have both
>> a uwsgi application tweak and a middleware tweak for the job now).
>>
>> Thanks for writing this.
>>
>> It reminds me of a time, almost two years long, when I was using uwsgi.
>> Every now and then I had similar obscure issues that needed a hell of
>> debugging. After I migrated to Gunicorn all these issues stopped. So I'm
>> wondering: why are so many people using uwsgi? What am I missing?
>>
>> Antonis Christofides
>> http://djangodeployment.com
>>
>>
>> On 2017-09-13 15:35, Bernd Wechner wrote:
>>
>> Well, not a lot of insight from the broader community on this one, but a
>> warm thank you to Melvyn Sopacua who took the time to think about it a bit
>> and apply his experience which led me to:
>>
>> /usr/local/lib/python3.5/dist-packages/django/urls/base.py
>>
>> where I could instrument Django a bit and find out how and why it was adding
>> this bizarre prefix to the urls.
>>
>> Alas it's a tad complicated and I'll try and publish a module with the fix
>> some time soon (it relates to lighttpd, uwsgi, django interactions and the
>> management of SCRIPT_NAME and PATH_INFO environment variables which lighttpd
>> doesn't do to Django's satisfaction and so it needs tweaking and I have both
>> a uwsgi application tweak and a middleware tweak for the job now).
>>
>> Regards,
>>
>> Bernd.
>>
>>
>> Bernd Wechner wrote:
>>
>> OK, I've more or less solved my original problems in deploying in this
>> space. Well I've deployed and am happy.
>>
>> BUT, I am still bamboozled by something and wonder if anyone has any clue or
>> insights to share?
>>
>> I have these two urlpatterns defined:
>>
>> url(r'^list/(?P\w+)', views.view_List.as_view(), name='list')
>> url(r'^view/(?P\w+)/(?P\d+)$', views.view_Detail.as_view(),
>> name='view'),
>>
>> Works a charm with these template tags:
>>
>> List Players
>> View Player {{ o }} 
>>
>> That url tag produces these URLs:
>>
>> http://127.0.0.1:8000/list/Player
>> http://127.0.0.1:8000/view/Player/1
>>
>> And it works. I click the links and they work. Well I've been developing
>> this way for  a couple of years and it's always worked ;-). it's great!
>>
>> BUT, after deploying, this resolves on the home page to:
>>
>> http://leaderboard.space/list/Player
>>
>> And when I click it it works! Awesome. Happy as. Great stuff. Gotta love
>> Django!
>>
>> BUT, if is open this page:
>>
>> http://leaderboard.space/view/Player/1
>>
>> It renders fine, I see a great view of player 1.
>>
>> BUT, on that page is the good old list link from above, namely:
>>
>> List Players
>>
>> and on the dev site this resolves to:
>>
>> http://127.0.0.1:8000/list/Player
>>
>> and here is the thing I'm stuck on! On the deployed site it renders as:
>>
>> http://leaderboard.space/view/list/Player
>>
>> What? Where did that 'view' come from? Of course I click it I get a 404
>> error:
>>
>> Page not found (404)
>> Request Method:GET
>> Request URL:http://leaderboard.space/view/list/Player
>> Using the URLconf defined in CoGs.urls, Django tried these URL patterns, in
>> this order:
>>
>> ^$ [name='home']
>> ^admin/
>> ^login/$ [name='login']
>> ^logout/$ [name='logout']
>> ^fix [name='fix']
>> ^unwind [name='unwind']
>> ^check [name='check']
>> ^rebuild [name='rebuild']
>> ^kill/(?P\w+)/(?P\d+)$ [name='kill']
>> ^list/(?P\w+) [name='list']
>> ^view/(?P\w+)/(?P\d+)$ [name='view']
>> ^add/(?P\w+)$ [name='add']
>> ^edit/(?P\w+)/(?P\d+)$ [name='edit']
>> ^delete/(?P\w+)/(?P\d+)$ [name='delete']
>> ^leaderboards [name='leaderboards']
>> 

Re: FROM ONLY in Postgres back-end

[Christian Ledermann]

On 12 September 2017 at 14:32, Andrew Hankinson
 wrote:
> Hello,
>
> tl;dr I'm trying to implement 'temporal tables' [0] in Django with a
> Postgres backend, and I'm stuck on how to generate the appropriate SELECT
> ... FROM ONLY and UPDATE queries.
>
> The temporal tables pattern depends on having two mirror tables. For a
> simple example, let's call them "person" and "person_history". As records
> are changed in "person," the previous states of that table are stored in
> "person_history".
>
> The simplest way to implement table mirroring is to use "INHERITS" in
> Postgres, e.g.,
>
> CREATE TABLE person_history () INHERITS (person);
>
> This is the simplest since any changes to the 'person' schema will
> automatically be reflected in person_history. (And no, I haven't tested
> schema changes and column renaming and interactions with migrations with
> Django just yet... it will come later). I've implemented this as Operations
> in the table migrations.
>
> When a table linked by "INHERITS" is queried, it will query both the
> 'person' and 'person_history' tables by default. This will obviously break a
> lot of things in Django. (e.g., a .get() will return more than one row...)
> The easiest way around that is to change "FROM" to "FROM ONLY" in all SQL
> queries, e.g.,
>
> SELECT name FROM ONLY person WHERE id = 1;
>
> The same goes for UPDATE.
>
> The part where I'm stuck is trying to figure out at what level I start
> digging.

It depends

> Do I modify QuerySet to try and implement my own custom lookup
> code?

you can always do raw SQL queries, but that kind of defeats the
purpose of having an ORM.

> Or will I need to dig into the SQL compiler to do this?

Likely.

> Or is this
> whole thing a waste of my time?

even more likely

>
> Or maybe there's a magic hook somewhere I'm missing that will let me inject
> what I need. I'm hoping for this one, but I haven't gotten my hopes up. :)
>
> Thanks in advance for your help,
> -Andrew
>
> [0]
> http://clarkdave.net/2015/02/historical-records-with-postgresql-and-temporal-tables-and-sql-2011/
>
> --
> 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 https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/f3423173-d0ab-4c7c-a5af-1592947f07ca%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Best Regards,

Christian Ledermann

Newark-on-Trent - UK
Mobile : +44 7474997517

https://uk.linkedin.com/in/christianledermann
https://github.com/cleder/


<*)))>{

If you save the living environment, the biodiversity that we have left,
you will also automatically save the physical environment, too. But If
you only save the physical environment, you will ultimately lose both.

1) Don’t drive species to extinction

2) Don’t destroy a habitat that species rely on.

3) Don’t change the climate in ways that will result in the above.

}<(((*>

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CABCjzWqk-8p%2BqN9mLUfMuW2kAjP1Z7%3Dx8s3im78ARmsXrqkPjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: More bizarre URL behaviour after deploying

[Antonis Christofides]

> Alas it's a tad complicated and I'll try and publish a module with the fix
> some time soon (it relates to lighttpd, uwsgi, django interactions and the
> management of SCRIPT_NAME and PATH_INFO environment variables which lighttpd
> doesn't do to Django's satisfaction and so it needs tweaking and I have both a
> uwsgi application tweak and a middleware tweak for the job now).
Thanks for writing this.

It reminds me of a time, almost two years long, when I was using uwsgi. Every
now and then I had similar obscure issues that needed a hell of debugging. After
I migrated to Gunicorn all these issues stopped. So I'm wondering: why are so
many people using uwsgi? What am I missing?

Antonis Christofides
http://djangodeployment.com


On 2017-09-13 15:35, Bernd Wechner wrote:
> Well, not a lot of insight from the broader community on this one, but a warm
> thank you to Melvyn Sopacua who took the time to think about it a bit and
> apply his experience which led me to:
>
>     /usr/local/lib/python3.5/dist-packages/django/urls/base.py
>
> where I could instrument Django a bit and find out how and why it was adding
> this bizarre prefix to the urls.
>
> Alas it's a tad complicated and I'll try and publish a module with the fix
> some time soon (it relates to lighttpd, uwsgi, django interactions and the
> management of SCRIPT_NAME and PATH_INFO environment variables which lighttpd
> doesn't do to Django's satisfaction and so it needs tweaking and I have both a
> uwsgi application tweak and a middleware tweak for the job now).
>
> Regards,
>
> Bernd.
>
>
> Bernd Wechner wrote:
>>
>> OK, I've more or less solved my original problems in deploying in this space.
>> Well I've deployed and am happy.
>>
>> BUT, I am still bamboozled by something and wonder if anyone has any clue or
>> insights to share?
>>
>> I have these two urlpatterns defined:
>>
>>     url(r'^list/(?P\w+)', views.view_List.as_view(), name='list')
>>     url(r'^view/(?P\w+)/(?P\d+)$', views.view_Detail.as_view(),
>> name='view'),
>>
>> Works a charm with these template tags:
>>
>>     List Players
>>     View Player {{ o }} 
>>
>> That url tag produces these URLs:
>>
>>     http://127.0.0.1:8000/list/Player
>>     http://127.0.0.1:8000/view/Player/1
>>
>> And it works. I click the links and they work. Well I've been developing this
>> way for  a couple of years and it's always worked ;-). it's great!
>>
>> BUT, after deploying, this resolves on the home page to:
>>
>>     http://leaderboard.space/list/Player
>>
>> And when I click it it works! Awesome. Happy as. Great stuff. Gotta love 
>> Django!
>>
>> BUT, if is open this page:
>>
>>     http://leaderboard.space/view/Player/1
>>
>> It renders fine, I see a great view of player 1.
>>
>> BUT, on that page is the good old list link from above, namely:
>>
>>     List Players
>>
>> and on the dev site this resolves to:
>>
>>     http://127.0.0.1:8000/list/Player
>>
>> and here is the thing I'm stuck on! On the deployed site it renders as:
>>
>>     http://leaderboard.space/view/list/Player
>>
>> What? Where did that 'view' come from? Of course I click it I get a 404 
>> error:
>>
>> Page not found (404)
>> Request Method:    GET
>> Request URL:    http://leaderboard.space/view/list/Player
>> Using the URLconf defined in CoGs.urls, Django tried these URL patterns,
>> in this order:
>>
>>  1. ^$ [name='home']
>>  2. ^admin/
>>  3. ^login/$ [name='login']
>>  4. ^logout/$ [name='logout']
>>  5. ^fix [name='fix']
>>  6. ^unwind [name='unwind']
>>  7. ^check [name='check']
>>  8. ^rebuild [name='rebuild']
>>  9. ^kill/(?P\w+)/(?P\d+)$ [name='kill']
>> 10. ^list/(?P\w+) [name='list']
>> 11. ^view/(?P\w+)/(?P\d+)$ [name='view']
>> 12. ^add/(?P\w+)$ [name='add']
>> 13. ^edit/(?P\w+)/(?P\d+)$ [name='edit']
>> 14. ^delete/(?P\w+)/(?P\d+)$ [name='delete']
>> 15. ^leaderboards [name='leaderboards']
>> 16. ^json/game/(?P\d+)$ [name='get_game_props']
>> 17. ^json/leaderboards [name='json_leaderboards']
>> 18. ^static\/(?P.*)$
>>
>> The current path, view/list/Player, didn't match any of these.
>>
>> clearly. Because I don't look for this bizarre and newly introduced 'view'.
>>
>> Now to be clear, I have a way around this, but I am not looking for a
>> workaround here, I'm fishing for any clues that help me understand how the
>> url template tag generates its output and when and why it inserts a string
>> like this that seems to be the name of the view that the link is on!
>>
>> Mystery++ and PITA.
>>
>> Regards,
>>
>> Bernd.
>>
>
> -- 
> 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
> .

Re: More bizarre URL behaviour after deploying

[Melvyn Sopacua]

You're missing the fact that it's the scgi module of lighttpd is what
is causing it. uwsgi shouldn't fix it, as it has no idea if this is
intentional, for example when using mounts [1].
As can be seen in the WSGI spec, the WSGI client (uwsgi / gunicorn /
whathaveyou) should trust what is provided here [2]. If gunicorn does
it differently, it will prevent you from mounting an app in a virtual
location, say "/django/".

[1] 
http://uwsgi-docs.readthedocs.io/en/latest/Nginx.html#hosting-multiple-apps-in-the-same-process-aka-managing-script-name-and-path-info
[2] https://www.python.org/dev/peps/pep-0333/#environ-variables

On Wed, Sep 13, 2017 at 5:27 PM, Antonis Christofides
 wrote:
> Alas it's a tad complicated and I'll try and publish a module with the fix
> some time soon (it relates to lighttpd, uwsgi, django interactions and the
> management of SCRIPT_NAME and PATH_INFO environment variables which lighttpd
> doesn't do to Django's satisfaction and so it needs tweaking and I have both
> a uwsgi application tweak and a middleware tweak for the job now).
>
> Thanks for writing this.
>
> It reminds me of a time, almost two years long, when I was using uwsgi.
> Every now and then I had similar obscure issues that needed a hell of
> debugging. After I migrated to Gunicorn all these issues stopped. So I'm
> wondering: why are so many people using uwsgi? What am I missing?
>
> Antonis Christofides
> http://djangodeployment.com
>
>
> On 2017-09-13 15:35, Bernd Wechner wrote:
>
> Well, not a lot of insight from the broader community on this one, but a
> warm thank you to Melvyn Sopacua who took the time to think about it a bit
> and apply his experience which led me to:
>
> /usr/local/lib/python3.5/dist-packages/django/urls/base.py
>
> where I could instrument Django a bit and find out how and why it was adding
> this bizarre prefix to the urls.
>
> Alas it's a tad complicated and I'll try and publish a module with the fix
> some time soon (it relates to lighttpd, uwsgi, django interactions and the
> management of SCRIPT_NAME and PATH_INFO environment variables which lighttpd
> doesn't do to Django's satisfaction and so it needs tweaking and I have both
> a uwsgi application tweak and a middleware tweak for the job now).
>
> Regards,
>
> Bernd.
>
>
> Bernd Wechner wrote:
>
> OK, I've more or less solved my original problems in deploying in this
> space. Well I've deployed and am happy.
>
> BUT, I am still bamboozled by something and wonder if anyone has any clue or
> insights to share?
>
> I have these two urlpatterns defined:
>
> url(r'^list/(?P\w+)', views.view_List.as_view(), name='list')
> url(r'^view/(?P\w+)/(?P\d+)$', views.view_Detail.as_view(),
> name='view'),
>
> Works a charm with these template tags:
>
> List Players
> View Player {{ o }} 
>
> That url tag produces these URLs:
>
> http://127.0.0.1:8000/list/Player
> http://127.0.0.1:8000/view/Player/1
>
> And it works. I click the links and they work. Well I've been developing
> this way for  a couple of years and it's always worked ;-). it's great!
>
> BUT, after deploying, this resolves on the home page to:
>
> http://leaderboard.space/list/Player
>
> And when I click it it works! Awesome. Happy as. Great stuff. Gotta love
> Django!
>
> BUT, if is open this page:
>
> http://leaderboard.space/view/Player/1
>
> It renders fine, I see a great view of player 1.
>
> BUT, on that page is the good old list link from above, namely:
>
> List Players
>
> and on the dev site this resolves to:
>
> http://127.0.0.1:8000/list/Player
>
> and here is the thing I'm stuck on! On the deployed site it renders as:
>
> http://leaderboard.space/view/list/Player
>
> What? Where did that 'view' come from? Of course I click it I get a 404
> error:
>
> Page not found (404)
> Request Method:GET
> Request URL:http://leaderboard.space/view/list/Player
> Using the URLconf defined in CoGs.urls, Django tried these URL patterns, in
> this order:
>
> ^$ [name='home']
> ^admin/
> ^login/$ [name='login']
> ^logout/$ [name='logout']
> ^fix [name='fix']
> ^unwind [name='unwind']
> ^check [name='check']
> ^rebuild [name='rebuild']
> ^kill/(?P\w+)/(?P\d+)$ [name='kill']
> ^list/(?P\w+) [name='list']
> ^view/(?P\w+)/(?P\d+)$ [name='view']
> ^add/(?P\w+)$ [name='add']
> ^edit/(?P\w+)/(?P\d+)$ [name='edit']
> ^delete/(?P\w+)/(?P\d+)$ [name='delete']
> ^leaderboards [name='leaderboards']
> ^json/game/(?P\d+)$ [name='get_game_props']
> ^json/leaderboards [name='json_leaderboards']
> ^static\/(?P.*)$
>
> The current path, view/list/Player, didn't match any of these.
>
> clearly. Because I don't look for this bizarre and newly introduced 'view'.
>
> Now to be clear, I have a way around this, but I am not looking for a
> workaround here, I'm fishing for any clues that help me understand how the
> url template tag generates its output and when and why it inserts a string
> like this that seems to be the name of the 

Re: Migration Woes: TypeError: int() argument must be a string... on ForeignKeys

[Melvyn Sopacua]

The issue didn't crop up, because there were no rows when you added
the field, so default isn't called. If you had existing data, then it
would've triggered.

What default should return for foreign keys is actually documented:

> For fields like ForeignKey that map to model instances, defaults should be 
> the value of the field they reference (pk unless to_field is set) instead of 
> model instances.

https://docs.djangoproject.com/en/1.11/ref/models/fields/#default

On Wed, Sep 13, 2017 at 4:39 PM, Matthew Pava  wrote:
> Okay, after much investigation, I found that the default value on this exact
> field was actually a callable that returned an instance of DisplayName
> rather than the pk.  After changing that, the migrations ran successfully.
> I wonder if Django could provide a better hint of such issues.  It’s strange
> because that default was on the previous migration file in the AddField
> command, but the migrate command never threw an error.  It only threw it on
> AlterField, and the default didn’t even have to be specified in the
> AlterField version.
>
>
>
> Thank you,
>
> Matthew
>
>
>
> From: django-users@googlegroups.com [mailto:django-users@googlegroups.com]
> On Behalf Of Matthew Pava
> Sent: Tuesday, September 12, 2017 4:09 PM
> To: django-users@googlegroups.com
> Subject: Migration Woes: TypeError: int() argument must be a string... on
> ForeignKeys
>
>
>
> I’m trying to alter my foreign keys on my audit log models to allow for
> null.  Django creates a new migration file, with an operation something like
> below:
>
>
>
> migrations.AlterField(
>
> model_name='checklistauditlogentry',
>
> name='usage',
>
> field=models.ForeignKey(null=True,
> on_delete=django.db.models.deletion.CASCADE,
> related_name='_auditlog_checklistusages', to='general.DisplayName'),
>
> )
>
>
>
> Upon applying the migrations, I get this error (without full path shown):
>
> TypeError: int() argument must be a string, a bytes-like object or a number,
> not 'DisplayName'
>
>
>
> I just can’t seem to figure this one out.  I can’t just delete the
> migrations and start over because I really need Django to modify the
> database to remove the requirement on those fields.
>
>
>
> Full trace:
>
> Running migrations:
>
>   Applying documents.0002_auto_20170912_1445...Traceback (most recent call
> last):
>
>   File "manage.py", line 10, in 
>
> execute_from_command_line(sys.argv)
>
>   File "\lib\site-packages\django\core\management\__init__.py", line 364, in
> execute_from_command_line
>
> utility.execute()
>
>   File "\lib\site-packages\django\core\management\__init__.py", line 356, in
> execute
>
> self.fetch_command(subcommand).run_from_argv(self.argv)
>
>   File "\lib\site-packages\django\core\management\base.py", line 283, in
> run_from_argv
>
> self.execute(*args, **cmd_options)
>
>   File "\lib\site-packages\django\core\management\base.py", line 330, in
> execute
>
> output = self.handle(*args, **options)
>
>   File "\lib\site-packages\django\core\management\commands\migrate.py", line
> 204, in handle
>
> fake_initial=fake_initial,
>
>   File "\lib\site-packages\django\db\migrations\executor.py", line 115, in
> migrate
>
> state = self._migrate_all_forwards(state, plan, full_plan, fake=fake,
> fake_initial=fake_initial)
>
>   File "\lib\site-packages\django\db\migrations\executor.py", line 145, in
> _migrate_all_forwards
>
> state = self.apply_migration(state, migration, fake=fake,
> fake_initial=fake_initial)
>
>   File "\lib\site-packages\django\db\migrations\executor.py", line 244, in
> apply_migration
>
> state = migration.apply(state, schema_editor)
>
>   File "\lib\site-packages\django\db\migrations\migration.py", line 129, in
> apply
>
> operation.database_forwards(self.app_label, schema_editor, old_state,
> project_state)
>
>   File "\lib\site-packages\django\db\migrations\operations\fields.py", line
> 216, in database_forwards
>
> schema_editor.alter_field(from_model, from_field, to_field)
>
>   File "\lib\site-packages\django\db\backends\base\schema.py", line 515, in
> alter_field
>
> old_db_params, new_db_params, strict)
>
>   File "\lib\site-packages\django\db\backends\postgresql\schema.py", line
> 112, in _alter_field
>
> new_db_params, strict,
>
>   File "\lib\site-packages\django\db\backends\base\schema.py", line 612, in
> _alter_field
>
> old_default = self.effective_default(old_field)
>
>   File "\lib\site-packages\django\db\backends\base\schema.py", line 229, in
> effective_default
>
> default = field.get_db_prep_save(default, self.connection)
>
>   File "\lib\site-packages\django\db\models\fields\related.py", line 963, in
> get_db_prep_save
>
> return self.target_field.get_db_prep_save(value, connection=connection)
>
>   File "\lib\site-packages\django\db\models\fields\__init__.py", line 770,
> in get_db_prep_save
>
> prepared=False)
>
>   File 

RE: FROM ONLY in Postgres back-end

[Matthew Pava]

If you want to do auditing of the database, I would look at packages available 
for Django.  This is the first I've read about "temporal tables," and my first 
impression is that of grave concern.
Django-reversion is a popular package:
https://github.com/etianen/django-reversion


-Original Message-
From: django-users@googlegroups.com [mailto:django-users@googlegroups.com] On 
Behalf Of Christian Ledermann
Sent: Wednesday, September 13, 2017 12:00 PM
To: django-users@googlegroups.com
Subject: Re: FROM ONLY in Postgres back-end

On 12 September 2017 at 14:32, Andrew Hankinson  
wrote:
> Hello,
>
> tl;dr I'm trying to implement 'temporal tables' [0] in Django with a 
> Postgres backend, and I'm stuck on how to generate the appropriate 
> SELECT ... FROM ONLY and UPDATE queries.
>
> The temporal tables pattern depends on having two mirror tables. For a 
> simple example, let's call them "person" and "person_history". As 
> records are changed in "person," the previous states of that table are 
> stored in "person_history".
>
> The simplest way to implement table mirroring is to use "INHERITS" in 
> Postgres, e.g.,
>
> CREATE TABLE person_history () INHERITS (person);
>
> This is the simplest since any changes to the 'person' schema will 
> automatically be reflected in person_history. (And no, I haven't 
> tested schema changes and column renaming and interactions with 
> migrations with Django just yet... it will come later). I've 
> implemented this as Operations in the table migrations.
>
> When a table linked by "INHERITS" is queried, it will query both the 
> 'person' and 'person_history' tables by default. This will obviously 
> break a lot of things in Django. (e.g., a .get() will return more than 
> one row...) The easiest way around that is to change "FROM" to "FROM 
> ONLY" in all SQL queries, e.g.,
>
> SELECT name FROM ONLY person WHERE id = 1;
>
> The same goes for UPDATE.
>
> The part where I'm stuck is trying to figure out at what level I start 
> digging.

It depends

> Do I modify QuerySet to try and implement my own custom lookup code?

you can always do raw SQL queries, but that kind of defeats the purpose of 
having an ORM.

> Or will I need to dig into the SQL compiler to do this?

Likely.

> Or is this
> whole thing a waste of my time?

even more likely

>
> Or maybe there's a magic hook somewhere I'm missing that will let me 
> inject what I need. I'm hoping for this one, but I haven't gotten my 
> hopes up. :)
>
> Thanks in advance for your help,
> -Andrew
>
> [0]
> http://clarkdave.net/2015/02/historical-records-with-postgresql-and-te
> mporal-tables-and-sql-2011/
>
> --
> 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 https://groups.google.com/group/django-users.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-users/f3423173-d0ab-4c7c-a5af-1592947f07ca%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Best Regards,

Christian Ledermann

Newark-on-Trent - UK
Mobile : +44 7474997517

https://uk.linkedin.com/in/christianledermann
https://github.com/cleder/


<*)))>{

If you save the living environment, the biodiversity that we have left, you 
will also automatically save the physical environment, too. But If you only 
save the physical environment, you will ultimately lose both.

1) Don’t drive species to extinction

2) Don’t destroy a habitat that species rely on.

3) Don’t change the climate in ways that will result in the above.

}<(((*>

--
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CABCjzWqk-8p%2BqN9mLUfMuW2kAjP1Z7%3Dx8s3im78ARmsXrqkPjA%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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/e251ad2de0ae494b90cf626eac560903%40ISS1.ISS.LOCAL.
For more options, visit https://groups.google.com/d/optout.

Re: FROM ONLY in Postgres back-end

[Andrew Hankinson]

Thanks for your replies.

I have looked at the other options available. While they are suitable for 
version control, they're not well suited for queries where you want to see 
the state of a given object at a given time. "Show me what X looked like on 
Y date" can be useful, and shouldn't require a reversion. In this case, I'm 
experimenting with developing an implementation of the Memento [1] standard 
within Django. 

http://mementoweb.org/guide/rfc/

I've figured out how to modify the SELECT query, and now I'm working on 
UPDATE. For select you need to subclass the Compiler and implement a custom 
`get_from_clause` method. UPDATE is a trickier, but I've made some progress.

Like I said, it may be stopped in its tracks when it comes to schema 
changes and migrations, but for now I'm satisfied with the amount of 
progress I'm making; it's all about finding which knobs to turn! 

Temporal Tables are a fairly well-established, if advanced, pattern in SQL 
servers, and is part of the spec in SQL 2011.

On Wednesday, 13 September 2017 18:36:46 UTC+1, Matthew Pava wrote:
>
> If you want to do auditing of the database, I would look at packages 
> available for Django.  This is the first I've read about "temporal tables," 
> and my first impression is that of grave concern. 
> Django-reversion is a popular package: 
> https://github.com/etianen/django-reversion 
>
>
> -Original Message- 
> From: django...@googlegroups.com  [mailto:
> django...@googlegroups.com ] On Behalf Of Christian 
> Ledermann 
> Sent: Wednesday, September 13, 2017 12:00 PM 
> To: django...@googlegroups.com  
> Subject: Re: FROM ONLY in Postgres back-end 
>
> On 12 September 2017 at 14:32, Andrew Hankinson  > wrote: 
> > Hello, 
> > 
> > tl;dr I'm trying to implement 'temporal tables' [0] in Django with a 
> > Postgres backend, and I'm stuck on how to generate the appropriate 
> > SELECT ... FROM ONLY and UPDATE queries. 
> > 
> > The temporal tables pattern depends on having two mirror tables. For a 
> > simple example, let's call them "person" and "person_history". As 
> > records are changed in "person," the previous states of that table are 
> > stored in "person_history". 
> > 
> > The simplest way to implement table mirroring is to use "INHERITS" in 
> > Postgres, e.g., 
> > 
> > CREATE TABLE person_history () INHERITS (person); 
> > 
> > This is the simplest since any changes to the 'person' schema will 
> > automatically be reflected in person_history. (And no, I haven't 
> > tested schema changes and column renaming and interactions with 
> > migrations with Django just yet... it will come later). I've 
> > implemented this as Operations in the table migrations. 
> > 
> > When a table linked by "INHERITS" is queried, it will query both the 
> > 'person' and 'person_history' tables by default. This will obviously 
> > break a lot of things in Django. (e.g., a .get() will return more than 
> > one row...) The easiest way around that is to change "FROM" to "FROM 
> > ONLY" in all SQL queries, e.g., 
> > 
> > SELECT name FROM ONLY person WHERE id = 1; 
> > 
> > The same goes for UPDATE. 
> > 
> > The part where I'm stuck is trying to figure out at what level I start 
> > digging. 
>
> It depends 
>
> > Do I modify QuerySet to try and implement my own custom lookup code? 
>
> you can always do raw SQL queries, but that kind of defeats the purpose of 
> having an ORM. 
>
> > Or will I need to dig into the SQL compiler to do this? 
>
> Likely. 
>
> > Or is this 
> > whole thing a waste of my time? 
>
> even more likely 
>
> > 
> > Or maybe there's a magic hook somewhere I'm missing that will let me 
> > inject what I need. I'm hoping for this one, but I haven't gotten my 
> > hopes up. :) 
> > 
> > Thanks in advance for your help, 
> > -Andrew 
> > 
> > [0] 
> > http://clarkdave.net/2015/02/historical-records-with-postgresql-and-te 
> > mporal-tables-and-sql-2011/ 
> > 
> > -- 
> > 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...@googlegroups.com . 
> > To post to this group, send email to django...@googlegroups.com 
> . 
> > Visit this group at https://groups.google.com/group/django-users. 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/django-users/f3423173-d0ab-4c7c-a5af-1592947f07ca%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
>
>
> -- 
> Best Regards, 
>
> Christian Ledermann 
>
> Newark-on-Trent - UK 
> Mobile : +44 7474997517 
>
> https://uk.linkedin.com/in/christianledermann 
> https://github.com/cleder/ 
>
>
> <*)))>{ 
>
> If you save the living environment, the biodiversity that we have left, 
> you will also automatically save the physical environment, too. But If you 
> only save the physical environment, you will ultimately lose both. 
>
> 1) Don’t 

Re: More bizarre URL behaviour after deploying

[Bernd Wechner]

Antonis,

Well truth be told I'm with uwsgi only because of the snowball effect 
you're alluding to, namely we have so many options I'm like looking 
on-line for what the most popular and recommended one is, and uwsgi has 
a huge fan base.  As to server, I opted for lighttpd only because I 
already have it installed (on an OpenWRT router the LuCI interface is 
driven by lighttpd by default) and so I wanted to keep to one system and 
installed it on the webserver too (so I've got one set of configs/quirks 
to keep my head wrapped around).


That said in the stack lighttpd->uwsgi->django for the issue I just 
fixed the least culpable and probably off scot-free is uwsgi. It's 
arguably a django bug.


The technical issue is that a URL like this:

        http://domain.tld/script/path

is split into these two variables by Lighttpd:

    SCRIPT_NAME: /script
    PATH_INFO: /path

and Django wants this:

    SCRIPT_NAME:
    PATH_INFO: /script/path

Now if you override get_wsgi_application you can pull the switch simply 
inside of the Django app you're writing with something like this in the 
WSGIHandler:


        environ['PATH_INFO'] = environ.get('SCRIPT_NAME','') + 
environ.get('PATH_INFO','')

    environ['SCRIPT_NAME'] = ''

and that works a charm. Everything rocks from there on in. It's lighttpd 
that does this split and Django that has the expectations, uwsgi is just 
providing the evironent lighttpd wants to pass on, and giving to 
Django.  It's not really at fault here in any way.


The specific issue I was hung on, was if you move this switch to 
middleware, where I think it is more at home because middleware is a 
well established and welcome way to inject code between Django and the 
outside world (hence middle ware) then the Django url template tag 
starts writing URLs like:


        http://domain.tld/script/script/path

What? And it turns out that IMO it's a Django bug of sorts, because 
Django squirrels SCRIPT_NAME away before calling middleware, so if you 
tweak SCRIPT_NAME in middleware, Django don't care no more. Which 
defeats the purpose of middleware. So IMO Django should squirrel 
SCRIPT_NAME away after middleware is run!


As it happens I explicitly squirrel it away for Django in the middleware 
and all comes good:


   from django.core.urlresolvers import set_script_prefix
   set_script_prefix(.request.environ['SCRIPT_NAME'])

And now the fiddle works in middleware too where I feel it's more at 
home than with a UWSGIHandler override (i.e. theoretically is more 
robust against Django evolutions).


Regards,

Bernd.

On 14/09/2017 1:27 AM, Antonis Christofides wrote:


Alas it's a tad complicated and I'll try and publish a module with 
the fix some time soon (it relates to lighttpd, uwsgi, django 
interactions and the management of SCRIPT_NAME and PATH_INFO 
environment variables which lighttpd doesn't do to Django's 
satisfaction and so it needs tweaking and I have both a uwsgi 
application tweak and a middleware tweak for the job now).

Thanks for writing this.

It reminds me of a time, almost two years long, when I was using 
uwsgi. Every now and then I had similar obscure issues that needed a 
hell of debugging. After I migrated to Gunicorn all these issues 
stopped. So I'm wondering: why are so many people using uwsgi? What am 
I missing?




--
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/3f1f50aa-3f1e-7ee8-23bc-bfa31a316256%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Why does Case/When ungroup the results of my values() annotate() query?

[Eric Palmitesta]

Hey all!

I've posted my question to StackOverflow and asked in #django on freenode 
but haven't gotten any responses, so I guess this mailing list is my next 
stop.

https://stackoverflow.com/questions/45802068/why-does-case-when-ungroup-the-results-of-my-values-annotate-query

It appears when I introduce Case/When to my annotate() query, things become 
"ungrouped".  Am I not using values() and annotate() correctly?

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/6a5cc926-d353-46f5-9edb-4dd507e33295%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Getting my head around ForeignKey, One-To-Many and Many-To-Many.

[Jack Razors]

I am creating a mindmap visio-like editor website using d3js and a bunch of 
custom javascript.  Rather than the schema/stencils being populated by 
static JSON files, I wanted to create an administration area to edit the 
schema without requiring JSON kung-fu skills and serve the dynamically 
generated JSON to my javascript app on the fly.  

I have 2 models that I am trying to figure out the best way to create a 
relationship between.

class EditorVocab(models.Model):
VOCAB_TYPES = (
('string', 'String'),
('textarea', 'Text Box'),
('list', 'List of values'),
('list-identifier', 'Open Vocabulary/Dictionary'),
('object_ref', 'Object Reference'),
)

vocab_name = models.CharField(max_length=255, unique=False, 
blank=False, null=False)
label = models.CharField(max_length=255, unique=False, blank=False, 
null=False)
help_text = models.CharField(max_length=255, unique=False, blank=True, 
null=True)
default_value = JSONField(default={}, blank=True, db_index=True)
vocab_type = models.CharField(max_length=255, choices=VOCAB_TYPES, 
unique=False, blank=False, null=False)

class Meta:
managed = True
db_table = 'editor_vocabularies'

def __str__(self):
return '%s (%s)' % (self.label, self.vocab_type)


class EditorStencil(models.Model):
stencil_type = models.CharField(max_length=32, unique=True)
stencil_name = models.CharField(max_length=128, unique=False)
stencil_icon = models.FileField(upload_to='stencils')
schema = models.ForeignKey(EditorSchema, on_delete=models.CASCADE)
vocab = models.ManyToManyField(EditorVocab, related_name="vocabs")
vocab_requirement = models.ManyToManyField(EditorVocab, 
related_name="required_vocabs", blank=True)

class Meta:
managed = True
db_table = 'editor_stencil'

def __str__(self):
return '%s (%s)' % (self.stencil_name, self.stencil_name)

I am using Postgres with the jsoneditor integrated into the Django Admin 
area and it works well.  What I would like to have is a One-to-Many 
relationship from EditorStencils -> EditorVocab and be able to 
select/edit/add which "vocabs" are apart of a stencil as well as required. 
 This works with ManyToManyFields but a vocab needs to belong to a stencil. 
 The way it is now, it could potentially belong to multiple stencils (which 
I do not want).

Thanks in advance!

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/55ae3904-85f7-44f0-a288-eaf6a97bdc98%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

django custom authentication

[yingi keme]

I have this code in my app view

from django.shortcuts import render
from django.contrib.auth.decorators import login_required


@login_required(login_url="login/")
def home(request):
return render(request, "home.html")


Here also is my project url

from django.conf.urls import url, include
from django.contrib import admin
from django.contrib.auth import views

urlpatterns = [
url(r'^admin/', admin.site.urls),
url(r'', include('log.urls')),
url(r'^login/$', views.login, {'template_name': 'login.html'}),
url(r'^logout/$', views.logout, {'next_page': '/login'}),

]


So i have the templates folder in my project root url and i have also 
configured TEMPLATES DIR in my settings.py

TEMPLATES = [
{
'BACKEND': 'django.template.backends.django.DjangoTemplates',
'DIRS': [os.path.join(BASE_DIR, 'templates')],
'APP_DIRS': True,
..
..
..
],
},
},


However, when i try to access my homepage,i expect it to render my custom 
login page(login.html). But it always say TemplateDoesNotExist.
I also tried putting the template folder inside an app. But the login page 
doesnt get rendered still.

I need help urgently.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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/44041d5a-5969-4397-91e1-ba245f68339c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Email validation in form

[Moreplavec]

Thanks. I made it as needed and wrote simple JS to call popup if there is 
an error to rise modal again after reload.

Thanks!

Dne úterý 12. září 2017 15:18:58 UTC+2 Daniel Roseman napsal(a):
>
>
> On Tuesday, 12 September 2017 14:18:29 UTC+1, Daniel Roseman wrote:
>>
>> On Tuesday, 12 September 2017 08:52:37 UTC+1, Moreplavec wrote:
>>>
>>> 
>>>
 {% csrf_token %}
 {{ form.non_field_errors }}
 {% for hidden in form.hidden_fields %}
 {{ hidden }}
 {% endfor %}
 {% for field in form.visible_fields %}
 
 {% if field.field.required %}
 {{ field.errors }}
 {{ field.label }}>>> class="special_class">*{{ field }}
 {% else  %}
 {{ field.label }} {{ field }}
 {% endif %}
 
 {% endfor %}
>>>
>>>
>> 

>>>
>> For some reason, you only show `{{ form.errors }}` if the field is 
>> required; and your email is not (becase you have blank=True in the model 
>> for that field). 
>>
>> Move the form.errors element out of that if block.
>> --
>> DR.
>>
>
> Sorry, that should have been `{{ field.errors }}`. 
>

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/4e09e9ad-768a-464f-a4b8-83a63c9531a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Email validation in form

[Melvyn Sopacua]

First, make sure the field is rendered as an input tag with type
"email". If it's not, your Django version is out of date or you're
overriding the widget somewhere.
Second, read this:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/email#Validation

The standard pattern isn't good enough as it doesn't require a dot in
the domain part.
This is why browser form validation succeeds and Django's fails.
Django could maybe propagate the validator
pattern to the "pattern" attribute of the input tag, but I'm not sure
that even works given various
browser differences in regex implementation.

The following css snippet, would allow you to test the pattern should
you decide to provide one yourself via widget attributes:

input[type='email']:invalid { color: red }


On Tue, Sep 12, 2017 at 5:23 PM, Moreplavec  wrote:
> I have {{ field.errors }}  im my template. I changed model to not contain
> blank=True, but problem is still the same.
>
>
> Dne úterý 12. září 2017 15:18:58 UTC+2 Daniel Roseman napsal(a):
>>
>>
>> On Tuesday, 12 September 2017 14:18:29 UTC+1, Daniel Roseman wrote:
>>>
>>> On Tuesday, 12 September 2017 08:52:37 UTC+1, Moreplavec wrote:

 
>
> {% csrf_token %}
> {{ form.non_field_errors }}
> {% for hidden in form.hidden_fields %}
> {{ hidden }}
> {% endfor %}
> {% for field in form.visible_fields %}
> 
> {% if field.field.required %}
> {{ field.errors }}
> {{ field.label }} class="special_class">*{{ field }}
> {% else  %}
> {{ field.label }} {{ field }}
> {% endif %}
> 
> {% endfor %}
>>>
>>>
> 
>>>
>>>
>>> For some reason, you only show `{{ form.errors }}` if the field is
>>> required; and your email is not (becase you have blank=True in the model for
>>> that field).
>>>
>>> Move the form.errors element out of that if block.
>>> --
>>> DR.
>>
>>
>> Sorry, that should have been `{{ field.errors }}`.
>
> --
> 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 https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/14a999b0-7bfc-4f5c-9215-b739e1ebf5e9%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 
Melvyn Sopacua

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CA%2Bgw1GVbpeS4Ci97nVOdLez_o-JrmzDz1s%2BC8h4PsuNDBZU78g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: More bizarre URL behaviour after deploying

[Melvyn Sopacua]

Humor me and call it list_view in the pattern and template references.


-- 
Melvyn Sopacua

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CA%2Bgw1GVNxjMJB6gTGKWUhshss9u_cG-Df4YAbC_U2Jq%2Bypf-nw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: More bizarre URL behaviour after deploying

[Bernd Wechner]

Well, not a lot of insight from the broader community on this one, but a 
warm thank you to Melvyn Sopacua who took the time to think about it a 
bit and apply his experience which led me to:


/usr/local/lib/python3.5/dist-packages/django/urls/base.py

where I could instrument Django a bit and find out how and why it was 
adding this bizarre prefix to the urls.


Alas it's a tad complicated and I'll try and publish a module with the 
fix some time soon (it relates to lighttpd, uwsgi, django interactions 
and the management of SCRIPT_NAME and PATH_INFO environment variables 
which lighttpd doesn't do to Django's satisfaction and so it needs 
tweaking and I have both a uwsgi application tweak and a middleware 
tweak for the job now).


Regards,

Bernd.


Bernd Wechner wrote:


OK, I've more or less solved my original problems in deploying in this 
space. Well I've deployed and am happy.


BUT, I am still bamboozled by something and wonder if anyone has any 
clue or insights to share?


I have these two urlpatterns defined:

url(r'^list/(?P\w+)', views.view_List.as_view(), name='list')
url(r'^view/(?P\w+)/(?P\d+)$', 
views.view_Detail.as_view(), name='view'),


Works a charm with these template tags:

List Players
View Player {{ o }} 

That url tag produces these URLs:

http://127.0.0.1:8000/list/Player
http://127.0.0.1:8000/view/Player/1

And it works. I click the links and they work. Well I've been 
developing this way for  a couple of years and it's always worked ;-). 
it's great!


BUT, after deploying, this resolves on the home page to:

http://leaderboard.space/list/Player

And when I click it it works! Awesome. Happy as. Great stuff. Gotta 
love Django!


BUT, if is open this page:

http://leaderboard.space/view/Player/1

It renders fine, I see a great view of player 1.

BUT, on that page is the good old list link from above, namely:

List Players

and on the dev site this resolves to:

http://127.0.0.1:8000/list/Player

and here is the thing I'm stuck on! On the deployed site it renders as:

http://leaderboard.space/view/list/Player

What? Where did that 'view' come from? Of course I click it I get a 
404 error:


Page not found (404)
Request Method:GET
Request URL: http://leaderboard.space/view/list/Player
Using the URLconf defined in CoGs.urls, Django tried these URL
patterns, in this order:

 1. ^$ [name='home']
 2. ^admin/
 3. ^login/$ [name='login']
 4. ^logout/$ [name='logout']
 5. ^fix [name='fix']
 6. ^unwind [name='unwind']
 7. ^check [name='check']
 8. ^rebuild [name='rebuild']
 9. ^kill/(?P\w+)/(?P\d+)$ [name='kill']
10. ^list/(?P\w+) [name='list']
11. ^view/(?P\w+)/(?P\d+)$ [name='view']
12. ^add/(?P\w+)$ [name='add']
13. ^edit/(?P\w+)/(?P\d+)$ [name='edit']
14. ^delete/(?P\w+)/(?P\d+)$ [name='delete']
15. ^leaderboards [name='leaderboards']
16. ^json/game/(?P\d+)$ [name='get_game_props']
17. ^json/leaderboards [name='json_leaderboards']
18. ^static\/(?P.*)$

The current path, view/list/Player, didn't match any of these.

clearly. Because I don't look for this bizarre and newly introduced 
'view'.


Now to be clear, I have a way around this, but I am not looking for a 
workaround here, I'm fishing for any clues that help me understand how 
the url template tag generates its output and when and why it inserts 
a string like this that seems to be the name of the view that the link 
is on!


Mystery++ and PITA.

Regards,

Bernd.



--
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/d3a95675-8137-ab90-54ea-b3e44ae6f53d%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Customized FROM clause/sort by computed annotation values

[stschindler]

Hey Django users,

I'm building a quite large query set that makes use of subqueries and lots 
of annotations. Here's the relevant part:

queryset = StockItem.objects \
  .order_by() \
  .annotate(available_stock_count=Subquery(stock_booking_count, 
output_field=IntegerField())) \
  .annotate(required_stock_count=Subquery(required_stock_count, 
output_field=IntegerField())) \
  .annotate(booked_stock_count=Subquery(booked_stock_count, 
output_field=IntegerField()))

There's another annotation I need, and that's a computed value (mainly 
needed for sorting reasons):

  .annotate(predicted_stock_count=(
F("available_stock_count") - (F("required_stock_count") + 
F("booked_stock_count"))
  ))

This works, however it only does because Django has an awesome smart query 
builder. ;-) Normally you can't use annotated fields (read: fields that are 
in the SELECT clause) for computing a new value in the same query. Django 
knows that and fills in the full subqueries again to make the computation 
happen.

Of course this increases the performance impact a lot. What you normally do 
in SQL to avoid that is something like this:

SELECT
  "inner".*,
  ("inner".x + "inner".y - "inner".u) computed_value
FROM (SELECT ... ALL THE HEAVY COMPUTATIONS) AS "inner"
ORDER BY computed_value ASC

Note the subquery after FROM. Everything from the inner query is forwarded, 
and a new value can be computed without issues, plus used for sorting.

Is this in any way possible with Django? I'm currently resorting to a raw 
SQL query that embeds str(queryset.query), but I lose all the benefits of 
having a real Django queryset, especially because I'm using REST Framework 
which highly depends on them.

Thanks!

Stefan Schindler

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/4191ef47-c343-42c5-9fe2-f05d2abedbed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Am a new Django User and am finding difficulties making a query to my database

[Melvyn Sopacua]

Well, the simplest answer is you used the python shell and not the
django shell via `python manage.py shell`.
The app not being in installed apps gives a slightly different error
and migrations have little to do with it as importing a model doesn't
hit the database.

So simply use `python manage.py shell`. Or do this:

% env DJANGO_SETTINGS_MODULE='myapp.settings' python
Python 3.6.2+ (heads/3.6:95b16a9, Jul 27 2017, 14:00:36)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from kernel.models import Gender
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/melvyn/hg/myapp/kernel/models/__init__.py", line 10, in 
from kernel.fields import *
  File "/home/melvyn/hg/myapp/kernel/fields.py", line 8, in 
from kernel.models.base import Country
  File "/home/melvyn/hg/myapp/kernel/models/base.py", line 8, in 
class UniquelyNamedDutchEnglishItem(models.Model):
  File 
"/home/melvyn/.local/py-env/myapp/lib/python3.6/site-packages/django/db/models/base.py",
line 110, in __new__
app_config = apps.get_containing_app_config(module)
  File 
"/home/melvyn/.local/py-env/myapp/lib/python3.6/site-packages/django/apps/registry.py",
line 247, in get_containing_app_config
self.check_apps_ready()
  File 
"/home/melvyn/.local/py-env/myapp/lib/python3.6/site-packages/django/apps/registry.py",
line 125, in check_apps_ready
raise AppRegistryNotReady("Apps aren't loaded yet.")
django.core.exceptions.AppRegistryNotReady: Apps aren't loaded yet.
>>> import django
>>> django.setup()
>>> from kernel.models import Gender
>>> # tada!


On Wed, Sep 13, 2017 at 1:16 PM, Oladipupo Elegbede
 wrote:
> Did you include your app in the installed apps list in your settings.py
> file?
>
> Did you do the makemigration and migration after creating the model?
>
> Check these two steps and then try again. That's what I'm suspecting given
> the error trace.
>
> On Sep 13, 2017 7:13 AM, "Abdul-Waris Dawuda"  wrote:
>>
>> Hello Everyone
>>
>> Am new to Django and am currently facing a problem trying to import a
>> class from my models.
>>
>> i get this error when i try to do that from the Shell. I am using Visual
>> Studio. i get this problem when i run my command to import;
>>
>> >>> from app.models import Artist
>>
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File ".\app\models.py", line 8, in 
>> class Artist(models.Model):
>>   File
>> "C:\Users\Abdul-Waris\source\repos\DjangoWebProject2\DjangoWebProject2\env\lib\site-packages\django\db\models\base.py",
>> line 110, in __new__
>> app_config = apps.get_containing_app_config(module)
>>   File
>> "C:\Users\Abdul-Waris\source\repos\DjangoWebProject2\DjangoWebProject2\env\lib\site-packages\django\apps\registry.py",
>> line 247, in get_containing_app_config
>> self.check_apps_ready()
>>   File
>> "C:\Users\Abdul-Waris\source\repos\DjangoWebProject2\DjangoWebProject2\env\lib\site-packages\django\apps\registry.py",
>> line 125, in check_apps_ready
>> raise AppRegistryNotReady("Apps aren't loaded yet.")
>> django.core.exceptions.AppRegistryNotReady: Apps aren't loaded yet.
>>
>> --
>> 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 https://groups.google.com/group/django-users.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/7b86f648-798a-4cb5-8fb9-cf2a7db83dd5%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 https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CAHjgLX5kzWiAsmEn%2BweL4D-TqezET0QMa-EBTXQH-U0%2BjKRg9Q%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 
Melvyn Sopacua

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CA%2Bgw1GWo%2BYUm%3DUPeZQr75K1OxENJZ7JTPmggpDnekzKUmLStUg%40mail.gmail.com.
For more options, visit 

Install uWSGI on cygwin

[Dick Pan]

Hi,

When I install uWSGI on cygwin by command: python2.7 uwsgiconfig.py --build

one strange problem occur, undefined reference to `uuid_generate' on cygwin.
but uuid.h exist in /usr/include/uuid/, and I checked GCC include path by 
command: echo | gcc -v -x c++ -E -, it's ok.

At last, I have to update core/uitls.c

change function uwsgi_uuid to following:

void uwsgi_uuid(char *buf) {  
*#ifdef UWSGI_UUID*
*#undef UWSGI_UUID*
*#endif*

can you help me to fix this problem in elegant methods?

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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/018f927b-66b4-4e48-b5bb-a40faac69082%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Am a new Django User and am finding difficulties making a query to my database

[Abdul-Waris Dawuda]

Hello Everyone
 
Am new to Django and am currently facing a problem trying to import a class 
from my models.

i get this error when i try to do that from the Shell. I am using Visual 
Studio. i get this problem when i run my command to import;

>>> from app.models import Artist

Traceback (most recent call last):
  File "", line 1, in 
  File ".\app\models.py", line 8, in 
class Artist(models.Model):
  File 
"C:\Users\Abdul-Waris\source\repos\DjangoWebProject2\DjangoWebProject2\env\lib\site-packages\django\db\models\base.py",
 
line 110, in __new__
app_config = apps.get_containing_app_config(module)
  File 
"C:\Users\Abdul-Waris\source\repos\DjangoWebProject2\DjangoWebProject2\env\lib\site-packages\django\apps\registry.py",
 
line 247, in get_containing_app_config
self.check_apps_ready()
  File 
"C:\Users\Abdul-Waris\source\repos\DjangoWebProject2\DjangoWebProject2\env\lib\site-packages\django\apps\registry.py",
 
line 125, in check_apps_ready
raise AppRegistryNotReady("Apps aren't loaded yet.")
django.core.exceptions.AppRegistryNotReady: Apps aren't loaded yet.

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/7b86f648-798a-4cb5-8fb9-cf2a7db83dd5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

I AM NOT ABLE TO IMPORT CLASSES FROM MY MODELS WHEN AM TRYING TO RUN A QUERY

[Abdul-Waris Dawuda]

When i run this command in the django shell when am trying to make query to 
my databse i get this problem. Kindly help me out:

>>>from app.models import Artist
Traceback (most recent call last):
  File "", line 1, in 
  File ".\app\models.py", line 8, in 
class Artist(models.Model):
  File 
"C:\Users\Abdul-Waris\source\repos\DjangoWebProject2\DjangoWebProject2\env\lib\site-packages\django\db\models\base.py",
 
line 110, in __new__
app_config = apps.get_containing_app_config(module)
  File 
"C:\Users\Abdul-Waris\source\repos\DjangoWebProject2\DjangoWebProject2\env\lib\site-packages\django\apps\registry.py",
 
line 247, in get_containing_app_config
self.check_apps_ready()
  File 
"C:\Users\Abdul-Waris\source\repos\DjangoWebProject2\DjangoWebProject2\env\lib\site-packages\django\apps\registry.py",
 
line 125, in check_apps_ready
raise AppRegistryNotReady("Apps aren't loaded yet.")
django.core.exceptions.AppRegistryNotReady: Apps aren't loaded yet.

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/8c958585-b868-45aa-98f1-26533aae5db8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Am a new Django User and am finding difficulties making a query to my database

[Oladipupo Elegbede]

Did you include your app in the installed apps list in your settings.py
file?

Did you do the makemigration and migration after creating the model?

Check these two steps and then try again. That's what I'm suspecting given
the error trace.

On Sep 13, 2017 7:13 AM, "Abdul-Waris Dawuda"  wrote:

> Hello Everyone
>
> Am new to Django and am currently facing a problem trying to import a
> class from my models.
>
> i get this error when i try to do that from the Shell. I am using Visual
> Studio. i get this problem when i run my command to import;
>
> >>> from app.models import Artist
>
> Traceback (most recent call last):
>   File "", line 1, in 
>   File ".\app\models.py", line 8, in 
> class Artist(models.Model):
>   File "C:\Users\Abdul-Waris\source\repos\DjangoWebProject2\
> DjangoWebProject2\env\lib\site-packages\django\db\models\base.py", line
> 110, in __new__
> app_config = apps.get_containing_app_config(module)
>   File "C:\Users\Abdul-Waris\source\repos\DjangoWebProject2\
> DjangoWebProject2\env\lib\site-packages\django\apps\registry.py", line
> 247, in get_containing_app_config
> self.check_apps_ready()
>   File "C:\Users\Abdul-Waris\source\repos\DjangoWebProject2\
> DjangoWebProject2\env\lib\site-packages\django\apps\registry.py", line
> 125, in check_apps_ready
> raise AppRegistryNotReady("Apps aren't loaded yet.")
> django.core.exceptions.AppRegistryNotReady: Apps aren't loaded yet.
>
> --
> 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 https://groups.google.com/group/django-users.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-users/7b86f648-798a-4cb5-8fb9-cf2a7db83dd5%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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAHjgLX5kzWiAsmEn%2BweL4D-TqezET0QMa-EBTXQH-U0%2BjKRg9Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: The view blog.views.create didn't return an HttpResponse object. It returned None instead.can any one help me this issue please nooob here

[Melvyn Sopacua]

And to be complete:

from django.http.response import HttpResponseNotAllowed
# in create
else:
return HttpResponseNotAllowed(['get', 'post'])

On Tue, Sep 12, 2017 at 2:08 AM, Luis Zárate  wrote:
> if request.method == "GET":
> if request.method == "POST":
>
> Uppercase is needed.
>
> 2017-09-11 17:36 GMT-06:00 harsh sharma :
>>
>>  here i m learning django and i m stuck on one thing
>> the web page returning
>>
>> The view blog.views.create didn't return an HttpResponse object. It
>> returned None instead.
>>
>>
>>
>> and here is my views.py  file
>>
>>
>>
>> def home(request):
>>
>> story = Story.objects.all()
>> return render_to_response('show.html',{'story':story})
>>
>>
>>
>>
>> def create(request):
>> if request.method == "get":
>> form = storyform()
>> return render(request,'form.html',{'form':form})
>> elif request.method == "post":
>> form= storyform(request.POST)
>> form.save()
>> return HttpResponseRedirect('/home')
>>
>> --
>> 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 https://groups.google.com/group/django-users.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/067af0b0-6761-4daf-a1c0-02fcd1585048%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> "La utopía sirve para caminar" Fernando Birri
>
>
> --
> 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 https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CAG%2B5VyMqn-Z%3Das%3DYxf_oph5yvDfUi%2BZWU1Uf_554fOTC2y3rsA%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.



-- 
Melvyn Sopacua

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CA%2Bgw1GUx-0panGx-KCmJ8Q8v0M_%3DU5FN3grp6iUtZXQnLGoF3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Install uWSGI on cygwin

[Avraham Serour]

try using pip: 'pip install uwsgi'


On Wed, Sep 13, 2017 at 11:35 AM, Dick Pan  wrote:

> Hi,
>
> When I install uWSGI on cygwin by command: python2.7 uwsgiconfig.py
> --build
>
> one strange problem occur, undefined reference to `uuid_generate' on
> cygwin.
> but uuid.h exist in /usr/include/uuid/, and I checked GCC include path by
> command: echo | gcc -v -x c++ -E -, it's ok.
>
> At last, I have to update core/uitls.c
>
> change function uwsgi_uuid to following:
>
> void uwsgi_uuid(char *buf) {
> *#ifdef UWSGI_UUID*
> *#undef UWSGI_UUID*
> *#endif*
>
> can you help me to fix this problem in elegant methods?
>
> 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 https://groups.google.com/group/django-users.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-users/018f927b-66b4-4e48-b5bb-a40faac69082%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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFWa6tLQ3ka_MWu0Fm7HFuCMr72khoOUsE91LGQtfRKrOBuoRg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Dynamically adding a field to a model - via contribute_to_class

[Michal Petrucha]

On Tue, Sep 12, 2017 at 12:34:26AM -0700, gernot.c...@gmail.com wrote:
> Hi,
> 
> I don't know if crossposting with stackoverflow is allowed here but 
> essentially my problem is explained 
> in 
> https://stackoverflow.com/questions/46162104/django-dynamic-model-fields-and-migrations.
> What I want to create is a custom ModelField of type DecimalField, that 
> dynamically adds another ModelField (CharField) to the source model. As far 
> as I can tell, this is nicely explained 
> in 
> https://blog.elsdoerfer.name/2008/01/08/fuzzydates-or-one-django-model-field-multiple-database-columns/.
> 
> Let's assume I start with a fresh project and app and add this code to 
> models.py:
> 
> from django.db import models
> from django.db.models import signals
> 
> 
> _currency_field_name = lambda name: '{}_extension'.format(name)
> 
> 
> class PriceField(models.DecimalField):
> 
> def contribute_to_class(self, cls, name):
> # add the extra currency field (CharField) to the class
> if not cls._meta.abstract:
> currency_field = models.CharField(
> max_length=3, 
> editable=False,
> null=True, 
> blank=True
> )
> cls.add_to_class(_currency_field_name(name), currency_field)
> # add the original price field (DecimalField) to the class
> super().contribute_to_class(cls, name)
> 
> # TODO: set the descriptor
> # setattr(cls, self.name, FooDescriptor(self))
> 
> 
> class FooModel(models.Model):
> 
> price = PriceField('agrh', decimal_places=3, max_digits=10, 
> blank=True, null=True)
> 
> 
> If I then call *./manage.py makemigrations* the following migration file 
> for the app is created:
> 
> # Generated by Django 1.11.4 on 2017-09-11 18:02
> from __future__ import unicode_literals
> 
> from django.db import migrations, models
> import testing.models
> 
> 
> class Migration(migrations.Migration):
> 
> initial = True
> 
> dependencies = [
> ]
> 
> operations = [
> migrations.CreateModel(
> name='FooModel',
> fields=[
> ('id', models.AutoField(auto_created=True, primary_key=True, 
> serialize=False, verbose_name='ID')),
> ('price', testing.models.PriceField(blank=True, 
> decimal_places=3, max_digits=10, null=True, verbose_name='agrh')),
> ('price_extension', models.CharField(blank=True, 
> editable=False, max_length=3, null=True)),
> ],
> ),
> ]
> 
> 
> All good, as far as I can tell. The problem comes up if I then call 
> *./manage.py 
> migrate* which errors with the following exception:
> 
> ./manage.py migrate testing
> Operations to perform:
>   Apply all migrations: testing
> Running migrations:
>   Applying testing.0001_initial...Traceback (most recent call last):
>   File 
> "/usr/local/var/pyenv/versions/stockmanagement-3.6.2/lib/python3.6/site-packages/django/db/backends/utils.py",
>  line 63, in execute
> return self.cursor.execute(sql)
>   File 
> "/usr/local/var/pyenv/versions/stockmanagement-3.6.2/lib/python3.6/site-packages/django/db/backends/sqlite3/base.py",
>  line 326, in execute
> return Database.Cursor.execute(self, query)
> sqlite3.OperationalError: duplicate column name: price_extension
> 
[...]
> As said, I have a fresh project with no exisiting DB and tables so far. Why 
> is it complaining that there allready exista a column named 
> "price_extension"?. The migration file only contains one field called 
> "price_extension"?

I'm not quite certain about this, but I believe that when the
migration runner reconstructs a version of your FooModel, it iterates
over the list of fields, and adds each of them to the reconstructed
model class one by one. So what happens is that your custom PriceField
gets added, which in turn creates its price_extension field, and then
next thing, the migration runner adds the price_extension field one
more time. So you end up with two instances of the price_extension
field on the same model, and when eventually the create_model schema
operation is executed, it adds each of them as another column to the
table, which is obviously wrong.

As for what you could do to avoid this situation – I'd suggest that
you add an extra argument to PriceField which tells the field that it
shouldn't create the additional extension field. Then, you implement
the deconstruct method on the field, and include this additional flag.
That way, auto-detected migrations will include the extra argument to
the field instance, and there shouldn't be any duplication of the
extension field on the resulting models reconstructed by migrations.

Good luck,

Michal

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

SystemCheckError: (admin.E111)

[Amit Mishra]

Hey,

I am using python=  3.5 and
Django=  1.10.2

If I am running for the makemigrations --$  python3 manage.py 
makemigrations

OR 

Starting server --   $ python3 manage.py runserver 0.0.0.0:8000

Its returning errors for SystemCheckError

.../mydjangoproject# python3 manage.py makemigrations
SystemCheckError: System check identified some issues:

ERRORS:
: (admin.E111) The 
value of 'list_display_links[0]' refers to 'None', which is not defined in 
'list_display'.
: (admin.E111) The 
value of 'list_display_links[0]' refers to 'None', which is not defined in 
'list_display'.


And same errors for the runserver.

Please help How can I resolve this. 

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/a14ca186-079a-4cf3-808f-f8442b6353bf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: SystemCheckError: (admin.E111)

[Melvyn Sopacua]

What's not clear about the error?

There are two admin classes that have invalid list_display_links values.

The format is documented:
https://docs.djangoproject.com/en/1.10/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_display_links

And chances are you have:

list_display_links = (None, )  # notice the () and comma

If this isn't your software, consult the documentation of that
software - you probably have something not configured correctly.

On Wed, Sep 13, 2017 at 4:12 PM, Amit Mishra  wrote:
> Hey,
>
> I am using python=  3.5 and
> Django=  1.10.2
>
> If I am running for the makemigrations --$  python3 manage.py
> makemigrations
>
> OR
>
> Starting server --   $ python3 manage.py runserver 0.0.0.0:8000
>
> Its returning errors for SystemCheckError
>
> .../mydjangoproject# python3 manage.py makemigrations
> SystemCheckError: System check identified some issues:
>
> ERRORS:
> : (admin.E111) The
> value of 'list_display_links[0]' refers to 'None', which is not defined in
> 'list_display'.
> : (admin.E111) The
> value of 'list_display_links[0]' refers to 'None', which is not defined in
> 'list_display'.
>
>
> And same errors for the runserver.
>
> Please help How can I resolve this.
>
> --
> 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 https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/a14ca186-079a-4cf3-808f-f8442b6353bf%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Melvyn Sopacua

-- 
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 https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CA%2Bgw1GXJxtdPnjH5Ehx8r5Gh1mep3ZuQcmn5t%2BCRFUDwJREahg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

RE: Migration Woes: TypeError: int() argument must be a string... on ForeignKeys

[Matthew Pava]

Okay, after much investigation, I found that the default value on this exact 
field was actually a callable that returned an instance of DisplayName rather 
than the pk.  After changing that, the migrations ran successfully.  I wonder 
if Django could provide a better hint of such issues.  It’s strange because 
that default was on the previous migration file in the AddField command, but 
the migrate command never threw an error.  It only threw it on AlterField, and 
the default didn’t even have to be specified in the AlterField version.

Thank you,
Matthew

From: django-users@googlegroups.com [mailto:django-users@googlegroups.com] On 
Behalf Of Matthew Pava
Sent: Tuesday, September 12, 2017 4:09 PM
To: django-users@googlegroups.com
Subject: Migration Woes: TypeError: int() argument must be a string... on 
ForeignKeys

I’m trying to alter my foreign keys on my audit log models to allow for null.  
Django creates a new migration file, with an operation something like below:

migrations.AlterField(
model_name='checklistauditlogentry',
name='usage',
field=models.ForeignKey(null=True, 
on_delete=django.db.models.deletion.CASCADE, 
related_name='_auditlog_checklistusages', to='general.DisplayName'),
)

Upon applying the migrations, I get this error (without full path shown):
TypeError: int() argument must be a string, a bytes-like object or a number, 
not 'DisplayName'

I just can’t seem to figure this one out.  I can’t just delete the migrations 
and start over because I really need Django to modify the database to remove 
the requirement on those fields.

Full trace:
Running migrations:
  Applying documents.0002_auto_20170912_1445...Traceback (most recent call 
last):
  File "manage.py", line 10, in 
execute_from_command_line(sys.argv)
  File "\lib\site-packages\django\core\management\__init__.py", line 364, in 
execute_from_command_line
utility.execute()
  File "\lib\site-packages\django\core\management\__init__.py", line 356, in 
execute
self.fetch_command(subcommand).run_from_argv(self.argv)
  File "\lib\site-packages\django\core\management\base.py", line 283, in 
run_from_argv
self.execute(*args, **cmd_options)
  File "\lib\site-packages\django\core\management\base.py", line 330, in execute
output = self.handle(*args, **options)
  File "\lib\site-packages\django\core\management\commands\migrate.py", line 
204, in handle
fake_initial=fake_initial,
  File "\lib\site-packages\django\db\migrations\executor.py", line 115, in 
migrate
state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, 
fake_initial=fake_initial)
  File "\lib\site-packages\django\db\migrations\executor.py", line 145, in 
_migrate_all_forwards
state = self.apply_migration(state, migration, fake=fake, 
fake_initial=fake_initial)
  File "\lib\site-packages\django\db\migrations\executor.py", line 244, in 
apply_migration
state = migration.apply(state, schema_editor)
  File "\lib\site-packages\django\db\migrations\migration.py", line 129, in 
apply
operation.database_forwards(self.app_label, schema_editor, old_state, 
project_state)
  File "\lib\site-packages\django\db\migrations\operations\fields.py", line 
216, in database_forwards
schema_editor.alter_field(from_model, from_field, to_field)
  File "\lib\site-packages\django\db\backends\base\schema.py", line 515, in 
alter_field
old_db_params, new_db_params, strict)
  File "\lib\site-packages\django\db\backends\postgresql\schema.py", line 112, 
in _alter_field
new_db_params, strict,
  File "\lib\site-packages\django\db\backends\base\schema.py", line 612, in 
_alter_field
old_default = self.effective_default(old_field)
  File "\lib\site-packages\django\db\backends\base\schema.py", line 229, in 
effective_default
default = field.get_db_prep_save(default, self.connection)
  File "\lib\site-packages\django\db\models\fields\related.py", line 963, in 
get_db_prep_save
return self.target_field.get_db_prep_save(value, connection=connection)
  File "\lib\site-packages\django\db\models\fields\__init__.py", line 770, in 
get_db_prep_save
prepared=False)
  File "\lib\site-packages\django\db\models\fields\__init__.py", line 958, in 
get_db_prep_value
value = self.get_prep_value(value)
  File "\lib\site-packages\django\db\models\fields\__init__.py", line 966, in 
get_prep_value
return int(value)
TypeError: int() argument must be a string, a bytes-like object or a number, 
not 'DisplayName'
--
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 https://groups.google.com/group/django-users.
To view this discussion on the web