Re: How to find out when a fix will be released

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, Aug 28, 2019 at 01:59:01PM +0800, wd wrote:
> >
> > As a concrete example, consider a moment in time halfway between the
> > release of Django 5.1 and 5.2. At this point in time:
> >
> >- Features will be added to development master, to be released as
> >Django 5.2.
> >- Critical bug fixes will be applied to the stable/5.1.x branch, and
> >released as 5.1.1, 5.1.2, etc.
> >- Security fixes and bug fixes for data loss issues will be applied to
> >master and to the stable/5.1.x, stable/5.0.x, and stable/4.2.x (LTS)
> >branches. They will trigger the release of 5.1.1, 5.0.5, 4.2.8, etc.
> >- Documentation fixes will be applied to master, and, if easily
> >backported, to the latest stable branch, 5.1.x.
> >
> >
> I see the PR was merged at Feb 3, Django 2.2 tagged at Apr 1, so the PR is
> happened between 2.1 and 2.2, it should be released at 2.2 ?

What that document doesn't explain is when the branch gets cut off for
the upcoming release, and how backporting works during the
alpha/beta/RC phase. There's a roadmap document in the wiki [1] which
indicates that your PR got merged after the alpha release, which means
in order to be included in 2.2, it would have had to be backported.
The timing is really unfortunate there, since you missed the freeze by
just a couple of weeks, but at least you can be sure that it will land
in the next major release. I also suppose asking explicitly for a
backport at the time could have helped, but it's probably too late for
that now.


[1]: https://code.djangoproject.com/wiki/Version2.2Roadmap
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEUX01Y24NsLRJUN8tcDtP8g8z+SUFAl16FaUACgkQcDtP8g8z
+SVK8xAA2QUVfi+wBAB1cjuV5cGZ7usY1kyj9aZK+iA3+zXj2yFyzpYRAPPNfr50
x3S1LrK0/GbuN5rI7IDVr/JWnduCVH8b1Kd+fFEWQyZah1XQO6HvDau5n6YFGJJC
aAVSmd4fHyAg1P4Unpyi5nRCI4hzwTQQaQEGCCkLayTS0x6uZS7ocXiBEeGoZKdt
DNg9+Fw63vJTx6CG304amN1f40lq+fcYPEQDgAMvKLNIiZ0++hILGwWZmKpY8z9G
3efyrtyrG7B8jTRyU5+adHSdMttO5eJlSj2VFlcw61oapE4sOwa7t05it0Sv/eKv
Kb1Up66lKs8FVh2G3JriQ/fxfbg4NcEJDN+mlgnKncxwcCjuyi943JFXJxtBqnM1
jnJSjceN0cYtQcsia2eO/LBeavNCwRynMtUJkA05Nu7KnJVblXqDo+GcXbHOL71m
MLm9djoR07spKDWMQLrj5Ih39uMFzQUS04Psio7J8f9aka/HYDD40nNUDymoDEWy
zBrrgd0QQmiNmhXA6CGmog2D6JNS/L8YgcFYnAk17uwk0yivVMAupojgft5IEKU8
jDDwpEluodH2VAymU+mz0YC+C+XFrpOOBo8u2a8QIbh1lsEjJRAAWG0Wk3WgXjB7
z11f8H3/bd+LRAiPOgcmzJ5WZDvL2Z0y2/YkwA9XnaijhVc7Mn0=
=zqPA
-END PGP SIGNATURE-

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/20190912095341.xaongmyxfzksm67t%40konk.org.

Re: Django security releases issued: 2.2.2, 2.1.9 and 1.11.21

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, Jun 03, 2019 at 09:41:59PM +0800, wanbao jin wrote:
> What were those security issues? Could you briefly explain about it?
> 
> Thanks

They are described in the blog post that Carlton linked to in the
first email: https://www.djangoproject.com/weblog/2019/jun/03/security-releases/

And there's no need to send your reply to all three mailing lists
where this release was announced. ;)

Michal

> On Mon, Jun 3, 2019 at 7:17 PM Carlton Gibson 
> wrote:
> 
> > Today the Django team issued 2.2.2, 2.1.9, and 1.11.21 as part of our
> > security process. These releases address security issues, and we encourage
> > all users to upgrade as soon as possible:
> >
> > https://www.djangoproject.com/weblog/2019/jun/03/security-releases/
> >
> > --
> > 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/8A290D5D-F090-4323-8587-79B4B66E7587%40gmail.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/CAM82qv1te%3DtoASo8fC5qDMnN32A1htHgq5Yvotv847Kn9-AkUw%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEUX01Y24NsLRJUN8tcDtP8g8z+SUFAlz1JIwACgkQcDtP8g8z
+SWoUQ//dJU4SEcltnvcF1/uRHfKPTAytBWm+ZC+3jIxeDZ6lT7Us7lYf1YJXGNi
Atv4z+KnXUPAe6rP3ARMonSD4g2EZxwyn6j7AUCmwpsFJKlBww9NSxz3f9hC4jJB
vKNJoqGutKE7y43uhsO1IAom8ILHFBZ3eUFkp9X/MG5HhcqD/WfHBh79HLIr25BB
rUEqZae/9Zzs31wzwbVw04nawu5x/PuPZBWcBi3eZ9Ulggl6n8ifvTb8tBGcuZzp
yyuehhKMqkEKbA0irsPTitOZkHOTmQdFQp6klrQq7zvIQCLNsanHTaPPo/1ROIF+
nlV0gmmVzIoZ8XTxTShzq5ShX+KL9Dr6Mt+kuiKuskDcIIHrJOuU8qR9sznzwbvj
mLBPnS6FmwbqPe2jW5+sNSHl8QFoYZqnwhdS1/ILAEQk1s9LARhq4ohealtIuP6u
Qhyh6CxP8ciLwYEzVCBScLA/gSNc76cV9CPngm4rpHKJou0cgSXa9+EOmrBKx4sQ
QLrqHCRLdBmWgUWSUt51Ri+2ZqoYd6Bk4MHigYmHr8euJZq9Xb0PGmCoa6c39pT0
t31gXz1ItsZVGCyHXRHVR2tq5K/WUK0XS/a6kFu/MuNlWdUxkX1c6Q9e3I2xjL/k
uN7wtDyMK1IdiUGzbVckKd85RpYtbA/nAfVAgo8hq3EtEORYllg=
=c1bc
-END PGP SIGNATURE-

-- 
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/20190603134548.vokyfypmenfi6rvq%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Re: Composite Primary / Foreign Key support

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Lance,

I see that you've already received a number of replies, but I'll give
you my perspective, too.

On Mon, Feb 18, 2019 at 08:26:43AM +, 'Ellinghaus, Lance J' via Django 
users wrote:
> NONCONFIDENTIAL // EXTERNAL
> So, basically, Django will not be supporting Composite Primary Keys
> in the future?
> 
> Lance

That is not what I wrote – it is almost certainly possible for Django
to support this, but it will take a lot of effort, and a relatively
large refactor of ORM internals, enough so that it is unlikely to
happen unless someone steps up to sponsor the work over an extended
period of time.

Just to give you an idea of how much effort is needed here,
personally, I have spent well over half a year working on this full
time under GSoC, with support from some really skilled and smart
Django committers (taken all together, with all the research, and
trying to keep up with django master for some time, it might be close
a year, even, though spread over a much longer period of time), and it
still wasn't enough. Of course, I'm no 10x rockstar ninja, so someone
else might get the job done faster, but it's still a fair amount of
work.

There's a lot of material out there outlining how one might go about
this, the two DEPs were already pointed out by someone else, and the
latest thread on django-developers@ that summarized the topic was
https://groups.google.com/d/topic/django-developers/wakEPFMPiyQ/discussion
The one notable thing that is missing from all design documents that
I've seen (or written) is how to make this work with migrations.
Interactions with most other parts of Django have been described at
some length already.

This answer probably won't help you solve your immediate problem, and
I get that it's frustrating. Either way, that's where we are today.

Cheers,

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJcbBq2AAoJEHA7T/IPM/kl/oQQAIGotHVDPhiD646CZ3hACeqX
c0+U9g2fwhDl8yVauh+Ra9BSCY74TBYNky72PpBOJJF27q+QTTaGObG7j+Iiua/T
GWMYQNixaZrxxKhDYTO2Cpw9/2vsKGG92+ZjKMLV92dNGXTboFMZyubBaBwIh0wi
erHnVkhqeGuwlmlZHtW6vogjsqZMHK+bFEq3JH6x9v7/eMX3iOhRnJELN/zKcVZE
re49pHrkHtBEwAyhL3uYBdmG4HWdP2FTJ8qEPV97fuTm4ez+BFfqy3SaCd2wjgFG
5sssd8MSWSoY/2DIDJYyOJwaM+ogG8+4HjcnFy8eYG4cPAxcVFDT9o3SN/xHOMNH
rjJ5CVtWZI+XSAWupICLCe8ObKjmMGIgbbM9M6V5DdzUCuyUXBbT59sMABXnyBuQ
OxRLMdbkXz+wgfWRkhQLTj6TC8G0znZoCin1S8+vc6aM42qZA3RMj7wU5dRrgmX6
ln8nBwjibrsoXpdukCeGmgIgpuQqtUaBfbKZh2sfh0v34ZuYHuNd7iJVDP5BJ47R
COyH7QgKijBAxgjl+GHxbLG+lqbMgJKL4kqOVEMsuX2xZ08RYt+1Cpqlq9QpPdj3
UPCYnmB2H+jEhPxBZLsH7sjXbQQCAiUqtE++2BMRDgczR7dsdmeduY+0X7toK+0A
QOowjjbhXohOLpAbmYKj
=VheK
-END PGP SIGNATURE-

-- 
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/20190219150318.GE10973%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Composite Primary / Foreign Key support

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, Feb 11, 2019 at 01:08:41AM -0800, 'Lance Ellinghaus' via Django users 
wrote:
> I have seen references to people adding the support of composite primary 
> keys to Django for years, but it does not look like it has been added.
> 
> I have a number of legacy databases that I cannot add fields to but need to 
> be able to be queried through Django. They are read-only tables.
> A number of the tables are also related through Composite Foreign Keys and 
> I have seen some addons but not sure what is fully supported.
> 
> I am trying to use Django 2.1.5.
> 
> Any help or ideas would be appreciated, and saying  "Add a field to your 
> tables" is not an option.
> 
> Thank you.

Hi Lance,

I haven't been on top of this in recent years, but let me try.

When it comes to just composite primary keys, as long as you only need
read access, you might be able to get away with marking an arbitrary
field as the primary key. Using a non-unique field as the primary key
would make any writes to the database dangerous, but that's not your
case here. However, you also lose the invariant that filtering on the
“pk” field alias will match at most one row, which means the admin
would probably be off the table, too – since that assumes the “pk” is,
in fact, unique, and the same holds for any other package that makes
use of “pk”. You should still be okay in your own code, though.

For composite foreign keys, there is nowadays a private, undocumented
API, ForeignObject, which is what ForeignKey builds on. The general
ForeignObject lets you specify multiple fields that make up the
relation, you should be able to find some examples in the test suite
(there is a foreign_object package in there). Keep in mind that this
is an internal API, so it might change without warning.

Good luck,

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJcYXniAAoJEHA7T/IPM/kl8EAP/Rzaxqe0bDO6vkxb4/Mmmj5S
62t6Cfm3VqqK6NxYjRXG904jKwDI4HMH1SAs5fdVMh9vf+VBj/S5bcIpQbesqXbh
wbkcIn+mmnfhLDaHOGunYqp76tscBJv/rtxJZaX5NRLp7OraCWtbjRBtiw1fJ/tl
iJD0HRIk9zn0pqyX8GjeAyM0UR+uL1wwrvz8Ur85ASsc8pFThTP6ZMQoaEIgo9D+
HB3XfrhiOMd5Nb2SbjG4KCRe7alpFx83nuY53YVsv+8X+Nqp4Ndi7ch2Ni3jxxHf
R7qVJYsMp/l72CNb6KiT85sb6PwQyeVdvU78cXKjkIKDirskGgQIEW2OvK+ZXC3B
Aj4I+AMFXEKje8ITfW3/s/v+UNvVTNZHYC5NPZ6o50+YJFDoiwb0mpQMdUredWZk
nT2cYMgyPQA/XKN9w5vUCNbTebPG/AA7yCthXbOrHn9Xl+kICkXRjjl9fHRUs55Q
wgPqz0CFXPKaE+JFt/NABJzdSrki1y587GHsOb7hKFiQwS8DHU8WOMXkR3BGKEtN
q0gebcqKvVnjRwLLsBvB0h3uI/yifgBTp8G8/+tZ0WuNdongTe+yPzchxuRjgx10
e70xtBjgsyCQGRB3CPsgR2UelQOtAEt8ZyYwyPF5sQYOvQg1xjcYp87FqfqflSTE
6aQIMkXhKjKazmc/ew9F
=Ji5Z
-END PGP SIGNATURE-

-- 
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/20190211133426.GV10973%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Logging of full trace with Debug set to False

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, Jan 28, 2019 at 04:45:44AM -0800, Kevin Olbrich wrote:
> Hi Anirudh,
> 
> I am using uWSGI and not Gunicorn. At least for uWSGI, with Debug = False, 
> it only logs the HTTP status code but not exception (might be the same with 
> Gunicorn).
> I will try Sentry which provides a clean GUI and notification of new 
> problems. This also seems to work for my Celery tasks and Django admin 
> commands.

Since you're mentioning Celery, I thought it might be worth mentioning
that Celery performs some black magic ritual on the Python logging
config in its default configuration, which interferes with the way
Sentry handles errors – or at least that's been my experience. At one
point I noticed that errors happening inside Celery tasks didn't have
all the stack values, like ones from the regular request/response had.
I don't remember exactly how, and I don't have access to that code
base anymore, but I remember that we had to explicitly disable as much
of Celery's custom logging as we could in order to get that to work.
(Might be that things have improved since then, though.)

Good luck,

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJcTvuFAAoJEHA7T/IPM/kltD8P/0MfET5/KylfZM/BWHDz4+vn
8U7hr4Zraz5R+zzr4yq7Ow0tom4zWE0EqpYREv87A4tX7dHGITTQLbU+bCce/MNQ
tIVD2D498XsEBGRsNav0kOr6ATuWoPuJlLLSFYGbGHedCKz6UB+ftmwYhL7WOQgr
zE8LeLS37jbm02/z6DD25intYUpRbKeeSRjyqkc+6esUz2IAXVQQ1NcUtJjPbmvi
zJtyWUX/RXS3Wulrp8lwLJ7rThcFAh3wVmC/nJCHeBQFLDmmLZx08EEnV1w7uxwv
AcowzfrGPOYv7VcOK9K9KvUPCrIj3KovU4DPlffuX6xxy8FZTvIyDptJAaMnh9C+
i8So48kPL1TxBk1lPuWx8TLr+RR1y4LIy7KVwMgRyeFC5zGIdBiAFIwo9X5utdc9
1uuO07bGn9224vpk87zyizA8Q88Qeee7kco+a0v0f8+Xxz6oAKg9uf3broJ9nl99
jp6Pp9QTzlpYFnw0bjMDMI3KRLkAxbWmeuGtBt7tELKFfHoae3RtfCqNitvEhN07
rz44xC2dbwPvQdV2UMElX+jS9omk+8oEwgMNvOPXyAsf3NexwcuN0lzoo5MS2OpY
kkwbNCD0aeHtreY5BJrXgONmXd58OswZhsCbcvZXqhIJ1MxreCzasXVvF7ZNHp6z
daRHSphHWV6/sDLFFfGw
=6WLZ
-END PGP SIGNATURE-

-- 
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/20190128125429.GE10973%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Logging of full trace with Debug set to False

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, Jan 28, 2019 at 02:53:55AM -0800, Kevin Olbrich wrote:
> Hi!
> 
> I would like to catch and send all exceptions to a logging system.
> When Debug is set to False, all debug related information is lost (just a 
> HTTP 500 error message).
> 
> While Debug False works perfectly in production, I would like to log and 
> send the exceptions to a backend, where I can save them.
> This would allow me to fix bugs, that only occur once every month (because 
> nobody is able to reproduce).
> 
> Similar approach was the case with Testflight on iOS, where I got a message 
> for every App-crash.
> 
> How can I handle this?
> 
> Kind regards
> Kevin

Hi Kevin,

You can set up your backend logging to send logs to Sentry [1], for
example. You can either set up your own Sentry instance, or use the
commercial offering [2]. If you set up sentry as one of the default
logging handlers, it will catch all unhandled exceptions, and you'll
get a fancy stack trace for each, including the values of local
variables in each stack frame.

Cheers,

Michal


[1]: https://github.com/getsentry/sentry
[2]: https://sentry.io/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJcTuVkAAoJEHA7T/IPM/kl5skQAOVvT+gu33Cn9YuM5152LaN/
hO8jQ5qC85k62+Z+3ptx8xsLOSPpbivdrAWOEW2asgRUFpSzdvsvDpF5ARWUlO9D
3s7bTfNqnPATDjEdiBep4ZQd5eWtkw7aMhHOS6gnwl60zEqlH62MIqOj9NFRL5YV
MMsCTAnqcB2IqXsiGmpxUvc5c20WHac4ODwOkOBAY4CPd1O6s1bf44LtD2bTaJTR
py7KvwKJ+4wkhM89cjnP5etIhdsnPbv+hKry40rji/J/k8VAz2w702jnRc5W6a8d
mPlBYfdZS/tfnNDx+TO+fKgwny1xrrE55vXabVgyt3nQF+KQluf2Zw2Q4HzDhhZ+
6L0QU2xR+EzFHsXCdhUAVF9+0h6guJzNQ7qsSz9KlZoGB5a2Jdk8Q4ji/RBVaORx
GEZpRw/VWTn7/mLvCdOxOH8J/IMf9avyEm+CK8K23BMFqO7ydmtUIboN/MVQ1UJA
4Xjp3vm1zB5hcaS9AjAJ5/vn9ySPjE9deoBxqUuN7I30Vug/EqqDhBhqOCiiwp4p
V6OwPMqhhZig3cvmigvwhZoT+WXUQwrGAGodleBon8ajIUcB1dxyxbPnbeIzSKPg
9lNot8WLlQEwYN7HWVQRMTc0NtLRg4YTI7UZWcwAneznxrCwKyzdQV3PhiN5A1Kh
VRcuK/Cf70seqQEarfXL
=HFoa
-END PGP SIGNATURE-

-- 
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/20190128112004.GD10973%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Questions about MySQL notes in Django docs

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, Jan 23, 2019 at 11:09:32AM +0100, Carsten Fuchs wrote:
> Dear Django group,
> 
> can you please help me with some questions about
> https://docs.djangoproject.com/en/2.1/ref/databases/#mysql-notes ?
> (I've been using Django with an Oracle database for years, but I'm new to
> MySQL.)
> 
> a) Does "Django supports MySQL 5.6 and higher." cover MySQL 8? (I'm not sure
> about the status of some tickets and PRs.)
> 
> b) Why is the "mysqlclient" client the recommended choice?
> 
> c) Using MySQL 8 and considering
> https://code.djangoproject.com/ticket/18392, should we set utf8 or utf8mb4
> as the character set?
> https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-sets.html indicates
> that utf8 is an alias to the deprecated utf8mb3 even with MySQL 8.
> 
> d) Why is isolation level "read committed" preferred over "repeatable read"?
> The text says "Data loss is possible with repeatable read.", but how can
> "repeatable read" have data loss that "read committed" has not?

I can't answer the rest of your questions, but here's a discussion
that might shed some light on this for you (along with the tickets
linked from that thread):
https://groups.google.com/d/msgid/django-developers/1c8af1c8-23dd-4c79-85ce-9486290ae73f%40googlegroups.com

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJcSGR9AAoJEHA7T/IPM/klu9QP/A2hCcibyiFvKBVD2mGOl8Wm
373BMpdq07p5UW3LJHY/sxBy343UuhKqc8/tl7MYGk0l1VsdnIBDEO73AMQPDKE2
LSWdQa5vNWwQR6RR2HdyAmJRDCCCp79eJmLZ8NTBWFCrYYB+u8Oi8dw3dm7zWeRu
PiYaub0+f5WonwREt9x/Ezt5ztI30t65MCqOSTaZOnA2pKmdDYEshRorIdPLtrjA
9k2Uh8XJe/LnKStQy7Vj/L5OJDKGXP3L/GSj1r04ZDrIF9rjOcJMZrcoFBYKHewM
ofC0SVtYvsKx2wcngePAPIthkL0czi05tOeZD1qMRuaLuxQ3zHpr3LFIgfsFn80C
tDjpS6/P8iwi+XWbIFtu2U90mzr1e5feIfgkd2bXxpZEUjdG+GaypJ+T0DEsozu+
ydrupUO4uOOhtQk0DawVkcz4ElM1fibfXFI4XS88c/Ykf9Ptoeib1fXqHxnMjXEf
bpkrqhZEHlnMUx1ftDy2FYE6Jqx9QT7diEaUbQPpggb+7MeJfMDHCiZlgwGijboy
8SUY31/0+lzgQ4v1NlaBU90lEVp8vehLI7qHpJhtPgBzfRxtANEX+O3ghoXlqv5d
Tqyuh0caL6sOOyZPiEhRhGWLvKTA9LmDhbAgJH2gABYnG+8BJZ6yYBHE89LXN4rd
NOYJAcID+ZrMC/wgudjc
=l01c
-END PGP SIGNATURE-

-- 
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/20190123125629.GG8269%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: problem in activating virtual environment in Django with ". \Scripts\activate" command

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, Jan 17, 2019 at 11:14:48AM -0800, Django Geek Aditya wrote:
> Shell Output after entering command is
> PS E:\todo> . \Scripts\activate
> . : The term '\Scripts\activate' is not recognized as the name of a cmdlet, 
> function, script file, or operable
> program. Check the spelling of the name, or if a path was included, verify 
> that the path is correct and try again.
> At line:1 char:3
> + . \Scripts\activate
> +   ~
> + CategoryInfo  : ObjectNotFound: (\Scripts\activate:String) 
> [], CommandNotFoundException
> + FullyQualifiedErrorId : CommandNotFoundException
> 
> PS E:\todo>

Hi Aditya,

The correct incantation for Powershell is

.\Scripts\activate.ps1

The version without any extension, or with .bat, would be correct if
you were running standard Windows cmd instead.

Good luck,

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJcQc8bAAoJEHA7T/IPM/kl/UwQAOW6VmD4ziMlE0iCWI6cebb5
omFIvG7cR5vT68RyONUiIJVhxOlGhEdkNTvrKsok7Kztp7ncOyK+b5WQgcDe32DS
bl6kJxXSNNSQOfE3KdprOn/5wOYtwdSHH8JNe4R6n/um7kVetjUbnkfraHoFBS5R
J0gKdpBkWEOEjoV/jJThzytvPjE0TgatcYthGLd8lrmAA9QQgIRguYNo+aRvFXv6
2n9uufi3wWLkA8Bv96qADa6vBgSBP6dtBKY3u73M/3U44q/OJO4LAbwYqqsVy032
Y2IGlTozqpFrSuu7yXH4DpCxy3o/WS20NFpmFYyQ9zlQbtldxfbLLQi/PWhi/xfm
bpwvG+InT0LvbYZsroaWBb9BX44ZkaDZMf4b6dVF7r1Unf/Win8YImK+mWxWu+iT
qMpIGAFGeawGuYYACkdw1DdgF7yqyiGYuDcCHCO6TyYVki5jW1nNHQV9Qyp8rcv9
SzH49ftAqn7PX+lXqrOke8G7+/2DMRSexVZoK3cTNMpeCkqwBrkghaBfr5vMGasI
4qNdWuzLiGkFv1lQWmb5Sm9e9eNAy0uFnTSzhsePT1J4Vs9tcr5y0A3/VY2dD8uv
gTZPj/lXcVTj4OetRRzjClhNiEqBAG3ji6wCIZ3yYlss+kHRX9q7Hm8dw7nROP6y
mnJHMuNJZVgxoiywqOX7
=pAUo
-END PGP SIGNATURE-

-- 
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/20190118130531.GB8269%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: No module named django.core.wsgi, Apache+ CentOS

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, Jan 15, 2019 at 08:04:23PM -0800, ANi wrote:
> Hey guys.

Maybe consider asking not just the guys next time. ;)

> I am trying to deploy my Django project on CentOS 7 with Apache.
> and I got an error of  *ImportError: No module named django.core.wsgi*
> I think it is because the Apache did not use the python version inside the 
> virtualenv
> However I dont know where the problem is.
> 
> this is my httpd.conf 
> WSGIProcessGroup project
> WSGIDaemonProcess project python-path=/var/www/html/project:/var/www/html/
> inv/Lib/python3.7/site-packages
> WSGIPythonPath /var/www/html/project:/var/www/html/inv/Lib/python3.7/site-
> packages
> 
> Alias /static "/var/www/html/project/static-files"
> 
> Require all granted
> 
> 
> 
> 
> 
> Require all granted
> 
> 
> I install wsgi_mod by *yum install mod_wsgi*
> [mpm_prefork:notice] [pid 25884] AH00163: Apache/2.4.6 (CentOS) OpenSSL/1.0.
> 2k-fips mod_fcgid/2.3.9 mod_wsgi/3.4 Python/2.7.5 configured -- resuming 
> normal operations

As the log line above indicates, the mod_wsgi you're using is built
against Python 2.7.5, but you're configuring it to point to a Python
3.7 environment; that will not work.

A quick search of the internets indicates that CentOS 7 does not
provide a mod_wsgi package built against any other version of Python
than 2.7, which means you'll need to build it yourself.

One way would be to use pip to install mod_wsgi in your application's
virtualenv (you'll need to ensure that you have all the necessary
header files for apache and Python installed), and then execute::

mod_wsgi-express module-config

which will show you the lines you need to insert into your apache
config in order to use that build of mod_wsgi. More details are
explained at
https://pypi.org/project/mod_wsgi/#connecting-into-apache-installation.

Good luck,

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJcPv4XAAoJEHA7T/IPM/klJ9MQAMYJ60aXMk2c1ZsqIP0yuRfS
GEOKVGM53pPTKWBt74fVkMSRCg8A6pC/Vmwka9f/wBCbG6/5QeFzYu0usuiTTGM0
m3KjjddEr0f7zr4KABkzsT9Q7F1gRymRqG3tqec40dLTPfLbiyITy5MUBGi0g8VS
cqSHfXhqQLHls3EjqH5gDgQy9i7J3GvJmjO5be9HEqnukO3o2NIff6mCnTmx1+TX
irvnXJ3th29j8Z7iHHl11JzWQgNQf4xKPZkpIb8x9DcZ66Its7fnx//bAkWcngAw
BpglB3GkAuyLi8XgTDlSEkwbNqJS00bjwZ/RWzfHwnXyu684quZMqDdLk7pJdn0I
uJH0d47zb3NHlOy1ODBrkds6QJMxW84x5jMpZnmeCs0O+h4A+zm42TFvTGKf7DlG
Tu8p5ZjMLD1oB1MEypdXJuURO2fUKigHHMjstBl7oJ04zoaZ8UWgJnMAxrjRCIJH
G0u4Un/O5cMTAKEzakaHvn0FJ5okwXhF+Pdn8g5oIPedBZNhiG4jg7cu4VjOz3/s
B/FADAh/ZHPkLe9aMe/I4L+oMxr4daCDw09TiT4eMFH8qYkIv+VBqRx9Gb7d0Fu5
Gp74k7cclszfSSfXZzIM+AAsDhTg+njzOgMO6tazYW/APBABOWQygvgtEGPvgOJo
Ln0azAuyh+PShZW5JXeg
=X2I7
-END PGP SIGNATURE-

-- 
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/20190116094912.GA8269%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with testing on Travis CI

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, Jan 16, 2019 at 09:11:47AM +0200, אורי wrote:
> Hi,
> 
> I recently have problems with testing my project on Travis CI. Tests
> started to fail 2 days ago. The error message is
> `psycopg2.OperationalError: FATAL:  database "speedy" does not exist` and I
> don't know why. It seems to me that the first test which fail for this
> reason is https://travis-ci.org/speedy-net/speedy-net/builds/479248003 and
> the commit is
> https://github.com/speedy-net/speedy-net/commit/04c4c891f64c4eee3accc393e59b5d18f0c8bbcc,
> but I don't know what in this commit causes the tests to fail. When I run
> the tests locally they run without problems. Do you know why our tests fail
> on Travis CI?

Hi Uri,

The problem is the following line:
https://github.com/speedy-net/speedy-net/commit/04c4c891f64c4eee3accc393e59b5d18f0c8bbcc#diff-c1494957b796412b658b8c2c97136711R6
That line tries to execute a database query during import, which will
not work – you don't want to make import-time queries, because those
will be routed to the production database even when you're running
tests, and they will also make it impossible for you to run migrations
in a fresh, empty database.

Good luck,

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJcPvvRAAoJEHA7T/IPM/kl4gsP/j2Pyl8YQsUi94saQFnIaEIH
sxQ28wm4a5vlfAyKxDDNZqcBBwVq0YPkpflEe5DnmFjQdcsanjZgxt+ejwwONmFF
+kP7gjD1mPmGG4V2XT5MllzI0VR5clZiP7leXgnQq+Xgtb0+xdfQHjZMm8JszhVe
oWbCgRlBNOXDPhnSS5mu5rh//zbBGaOQHjN6vcmmT+M7OQcjDD4nmsEnz3fY3b5J
mh3Y/X8h0dzCao0cAul7m8Pynu/xDl5THQS9dI4YIEOrzdQBkjNZMonNr0rK7e5o
49MbfHOGRmDNdF53w2AfKe+9FN/I+C9WXR6XQNE2858aveGM0o+hw+P+1RhNUPBF
/oov5rDu0vmyLDd2ip3lHZ0ki12mkMKYMZQ6Yfit4X1nLaob/6oQ4KkMCzawrIWS
CekjFC2HQY6SJJRpS0VGjft5qlRvEgO9isn+THoNDIEZDJj1XT07RJldA+6/g1Jy
POeneUyxa7j1F3gcW86lazCfavLO7LhPnAcWKjntc9j5Xq5/l0TyJcORV6yJFMSu
Wgh3YrqjIZcOMkX+YiJ0pr5iqkZ3M/hieLALuaM13iYbx1NtL+k34rx76ROz8sw4
BpAO/oUMJnDS+2yT/G2FmTdhJisznTjsqgwfyDSAdlMSpADjxNj62ykojgCTjhpB
J6DfyIn1PH3LaTeWK4bi
=zAwN
-END PGP SIGNATURE-

-- 
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/20190116093929.GZ8269%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Using the Models from two Different Projects in a single script

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, Jan 15, 2019 at 03:04:23PM +0530, Glen D souza wrote:
> Hi,
> 
> I have two different django projects which each project having different
> model
> 
> Lets say projects to be p1 and p2
> 
> 
> Now i have to populate the data from p1 model to a model in p2 ( note p1
> and p2 models are different, i just have to use some data from p1 model to
> move to p2)
> 
> 
> Now in order to write the script i have to initialise two different django
> projects, something like
> 
> 
> os.environ.setdefault('DJANGO_SETTINGS_MODULE', "p1.settings")
> django.setup()
> 
> 
> settings.configure("p2.settings", DEBUG=True)
> django.setup()
> 
> 
> So i was wondering, is this even possible? and is there any other way

Hi Glen,

This won't work – Django uses a whole lot of global state to keep
track of all the settings, model registries, and so on.

I'd suggest an alternative approach, where you'd use a management
command to export the relevant data from one project (either just
dumpdata, or write your own, more specialized version), and then use
another management command in the other project to import the exported
data (again, either write your own custom importer, or use loaddata,
depending on whether you need to transform it in any way).

Good luck,

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJcPbANAAoJEHA7T/IPM/klSMIQALnCiWUeVCvKvjVnrk6bboYX
abN8NrPjO/rEwVzqMnxw1V5wZvJ12SgK/hQMiiaO+LKMsbx0D8PSWTlZdPRzBWOi
asXnlxKdrEy/2zT7ohW0DGdl8mwltqIdkqtbAZl4T9/+gOwUiFIdvfw1SKX/Zbrx
rTXBKb/cwixUymfRPmdX0ML4d9NTQ4JD4N2RW1OKtMrn2PpfdW9nqtiukFC16ExX
8Zbow6SQHL5m2VfR/FJIdXY2ueG7RRm6TPrrHUF6ww3NIKBx1grUHw6vcyIW3ueb
YE0dDIhK0Xcj0zxwjumxjKG/Snzlrwc2TKtOM0syf3FXdgv4IWnP0iqj6i8R9hwM
F5x+4WsFrBbd6hLlNWXGmcwa5VzdxHSI0fZzVbtQI5gfMKVyk0byWdHIBlgNhBd6
SzwkGN2AgK+++cMwwGNKpiuo27EOS/ilHD7oLBTDSXcKFJ7UU9Unp56at+2mmd82
SjZsoDnoYoeOiuJ+Z6TMfvidvKrUJsuYqqZxWwlrUPLz1zWAyyWRdAq1n1fiZh3K
i8mr/n/QD64Jaq9KNZ+CU+/65Jicxg0bAtuvUuDrBUIirua9RJ+XEFTmphCWIobj
gBt5NPoR4ZkODukFG2N8IY3xxc9qEoZynTrhIxxpxcZJIdv2PoljsTnOk9BkUCYb
l+rHw0rgU2BZJkAd7AYg
=cOhG
-END PGP SIGNATURE-

-- 
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/20190115100357.GY8269%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: migrate failed due to Permission

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sun, Jan 13, 2019 at 11:49:44PM -0800, ANi wrote:
> Hello.
> 
> I want to migrate all tables into new database but bumped into an error 
> that it said "auth_permission" is not found.
> Then I searched for the possible causes, it turned out that it is because I 
> accessed the auth model "Permission" in my code before the migrate creating 
> table in database.
> I tried to run *python manage.py migrate auth, *but nothing changed.
> 
> So maybe I have to change my code ... I have to filter out managers by its 
> permission.
> 
> manager_permission = Permission.objects.get(codename='manager')
> managers = User.objects.filter(project=project).filter(user_permissions=
> manager_permission)
> 
> User.user_permissions is only allowed to use the permission code which 
> could be different every time I re-migrate the whole database.
> 
> So I am asking if there is a better way to filter out managers by its perm 
> or other solutions ? :)

Hi,

The problem is that you're not supposed to execute any database
queries when your application is getting imported – you should only do
that at runtime, when everything has been initialized, and when you're
handling a request (or a management command, or a background job, such
as celery, or whatnot).

It's a bit difficult to go into more detail, because you haven't
provided a whole lot of information, but those queries that you're
executing in module scope should go into functions and methods that
you only call when you actually need that data. It would be easier to
give you more specific advice if you posted the relevant parts of your
code, though.

Good luck,

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJcPMMcAAoJEHA7T/IPM/klYBEQAIq+exMdhBSLR7Vskpzavd2p
HHLIZYl9DuVOaxtW5sg0qIu92rLVGf8taPLzhIZJA5LHGlnYaFPMo0Bs6eNCdUnr
Bpxzt1xzJFiqou96NFFveG1N1ywCfAvPNqNhyTRJjX0iRv3n2LFk5XQ05V3GUcvv
V/+wvTm6ZlffVHuCWKIWypkY2yMZhFryTebmZOmavptNVMx5FpU4FcEBLufE5qvw
j0BmnvXRqUkuEhtyqGNcnjl496khb5Zu9zKfZcrjyDDvTlhC0nS4hS5MDZxkih6x
RfX2p0vjOctJhnKiywBIjOGNR5jFEYGCqVkyYds0rF6kNSvLRelxgJtB8Ms8yIkE
VffEsuVlS56DTtxIyyhJcnwYVA0JqO4QvEDY4VB6N7Is+Kd/dGrk0+qdhd4psawb
pNYhwWNMjvvl6aCpvPd+5rKFUW7I25mD2F+tx7/5EcVCp7767NG0nnMiSTqXnz5w
4aU09pzM7TCwr+2rTvdsM94jui/0bfWA437sLcpyQ+uALwzqc89i3vN4aVrnJRDv
W2Y1TJxS2v1uyqwvTYmx+7vNFT7lsDfFKKabwGvcMP7YdbwFCYNIvQKj229N3Y53
Fn25XOJe/WdfNAtzJP/m7UBuyaVorBZWVpFR4QHG+LTLRieEySmhgVe5seu9G50i
XCW0pAY72G3Kblzb4ZWI
=Nwlv
-END PGP SIGNATURE-

-- 
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/20190114171301.GX8269%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Set default value in field dependant on another model?

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, Jan 14, 2019 at 04:05:27PM +1100, Lachlan Musicman wrote:
> We have two models: Resources and Quota
> 
> Resources model instances include:
> - red things
> - yellow things
> - blue things
> 
> Quota have two fields, one is a FK to a Resource, the other is "desired
> quota".
> When instantiating the Quota request form, we create a form for each
> Resource.
> 
> I'd like to autofill the "desired quota" field on each form, but make it
> dependent on which Resource it is representing.
> 
> IE, when someone makes a resource request, we expect them to want
> 
> 1 red thing
> 5 yellow things
> 10 blue things
> 
> Do some searching, there's a lot pointing to Signals, but I remember
> someone once saying "if you are using signals, you should re-write you
> logic" or somesuch, so I thought I'd ask here.
> 
> FWIW - and this is well beyond my control - we are on Django 1.8

Hi Lachlan,

This sounds like logic that would be triggered by the view handling
the form – when you're displaying a new empty form, ask your business
logic layer for the default number of things to request in a new
“Quota” for that specific resource, and then pass that number to your
form as the “initial” argument.

Cheers,

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJcPMF3AAoJEHA7T/IPM/kl7aMQAKxO1sPQptRYCDYFzh/7UVLL
pBxxHT258Bnd3Oos73U05HQX7cij2Ca0aiJaFFK3nhd8SRl+WAKrzyNT40JBaEGC
dXXZrVxU4aUcHWsUKmGsbEXDEejnyGUM2sNU3rVzfs7zBdJl69fHKAFCeRc+iCJ8
ckWb/f0QCzqxEu5mVDC6UVqxWZY5QNws2bJ9zIeWVQZHaAhIeJrmrklKEEbstodi
9QGh64NHNZSn9kgNHiBYP39TKaTxa8QTN0pojB/U0VPt46AUx3Dyq/03GwK/8+mN
F4eUViiTntTCFsY0Py6jGh9/Oc8Yx0dRaQfalCj2uq6BSMLzIG+aZ8ubhkLq3DkK
6WvJ/nhhVNRyFjHFjV5lk7R5V/2mOPBFzIuPeWhUDFqYX8RA+SIZyqdZ9iabTxIJ
JG5Cp5FYZ0ToteQq8hWZcE9e/ZoB6c/b3aJwQ8MIqcCp8Rmh3cyjVFa1z3r3UJmG
j73T15NMwNk9b7g91sfluqhBWtPL31mH/7qTDtNXYC6WWawqCiol7y/Yu0xn2iws
xmPUYM4CDkF257t8KJxLzU69qhcB0xtRaqD5F31ioM4S+3WfCpXXmYUk7kPUUDzP
7KMr6s4sMq7BtdVxP4P3NEgfnfmyPkhiFuGX+v9OqV2VdbGTe7UkLuwCeXlD5zBb
cY+/1Z/YnrNn+EaspENW
=bT81
-END PGP SIGNATURE-

-- 
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/20190114170600.GW8269%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Can a class which inherits from factory.DjangoModelFactory use Django TestCase asserts?

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sat, Jan 12, 2019 at 03:59:59PM +0200, אורי wrote:
> Hi,
> 
> I have a problem with tests. We defined a class called DefaultUserFactory
> which inherits from factory.DjangoModelFactory, and I want to use asserts
> in this class such as assertEqual. What is the best approach to do it? I
> tried to inherit both from factory.DjangoModelFactory and from Django class
> TestCase but it doesn't work. I thought about passing a parameter from the
> calling function and then call assertEqual of the calling function's self.
> But it seems too complicated. Is there a better approach?
> 
> You can see our code on GitHub:
> 
> master:
> https://github.com/speedy-net/speedy-net/blob/master/speedy/core/accounts/tests/test_factories.py
> 
> staging (under development):
> https://github.com/speedy-net/speedy-net/blob/staging/speedy/core/accounts/tests/test_factories.py

Hi,

The factory class is not really the place to put your test assertions.
That would be the responsibility of the code of your actual test
cases. Factories are just one of the tools that you happen to mostly
use in tests, but you can totally use them to generate a sample
database outside of an automated test environment.

Running this kind of test code in your factory would also have the
drawback that you'd run the same asserts over and over and over again
every single time you invoke the factory – which might be thousands of
times during one run of your test suite.

As I understand it, you want to test your factories, which is a good
idea. What I suggest you do is to just write a separate test module
for your factories.

Good luck,

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJcPL0tAAoJEHA7T/IPM/klKeUQAMYUPpVVXAazNEt6Ga2He5V3
ZmmCDyYqQIJvrDAEwX7S1HbOq2K+EjvKeL2/dAf0Si7SQJPsjHcElUOIuSs+ch+/
46C5KM+3LLf3v2H6u1793TQy+oImoaygv8Mp3OZ8j7bfUH2dsBiLhECmfwQz48Ra
Uw/p7FoKKsT5saVK/bA4uoI2mIrnBKCj2KiZyYbkRs928tP9tAYIsHAotSXHDZVo
at8yyJ+J1nFFAzhZPJWN72zK0Pw5RdPF2L3wOrRhVgHLDfYsaZI9O4+6HYBjKkPn
6YWTVG1xq5p+dfofvtdzzFOiDn2rBRWgLlx3zl9cVE6xY7HjaieCI1a9IaePFXy8
MRIytt1Cc41tyT1lCl2yFBc+NT0+DFZMizNUkTgdzwM2uL2BlIh3+GsEY82ZzX/H
iwZ8DSOVuE2Iqpo132LrqcllHqNehxSYya7WBeBYHJiuDq2b2OaJp6ko5eb13ukn
LaVZGVwl+dmSx9HhVDqYHWHxK7AuEiE0CI+Y7Oy7RQhSH97L2MEw1qQlt6UxZtiz
83U0+RbNjDqXN0oMhswHtbnvnqnvKMg5zHVjzoLdAxrT+IIWUAnP6IqIM9v4UkgX
1aPof7eI6nm//ZA+fjmjCRorF3rHi98ZeK0a9Xccakl09zNKX7Vc/nlIbQqlKV8e
YawH4kZesUSUWBkIuIV/
=0T5r
-END PGP SIGNATURE-

-- 
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/20190114164741.GV8269%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Creation of database in real time and loading it in the DATABASES variable of Django;

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, Jan 07, 2019 at 10:38:30AM -0800, Sanderson Carmona wrote:
> Good afternoon,
> 
> I'm using the latest version of Django (2.x) and I'm having a rather 
> complicated task because of the lack of experience I have with the 
> Framework.
> To do: I need to use 1 bank as default and others created in real time for 
> the contract client in the company.
> 
> Example: You purchased a service and when registering the system create a 
> database with standard tables for its use;
> When this client logs in the system will load information from the created 
> bank.
> To do this it should read in the database the name of the client's database 
> and load it into the DATABASES variable, that is, if not see another way.
> 
> If anyone can help me thank you very much, I already researched and did not 
> find anything on.
> Thank you

Hi,

Messing around with the DATABASES setting during application runtime
is a bad idea, you want to leave that static.

What you're describing sounds like multi-tenancy; there are a number
of packages for this that have been forked off of each other, which
solve this separation using one Postgres schema per tenant in a single
database. Right now the one that appears to be maintained would be
https://github.com/tomturner/django-tenants.

Good luck,

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJcNMOzAAoJEHA7T/IPM/klRJkP+wZX7rO2EKpbhID6iYH28d9j
nFyMBag0RWh4etYEm5FLxz3u+3IPmxoK9n8EuuaP79+XIqgXP/kdnQODd3Wl2I6e
q8TOUiEFAP1cmtbzMwlQ/llBLZZBUpy6SCWe3rlwiTnkV71JCMsu4Y7h3mWgSsT0
zedUXYYUlfwdNQMWy4F0AJA4CYimpZL8bW67ofdcWkg8fWfCegeLPGId7uCMYqlf
YfkuqP4YNSnjakJYyK5pxjHj11XfzR2fw6JZNl5mY48bAZW52/sasKzCzB80syXv
gRj6WJdMBn2nfUosW6MsqsF55IToEM9fsFzCxJZ/ztSrsIiJ7DqN/JEAmeEkEMuF
QA/2n6fFKlsK0VyrZWu61XmVvhGc5FZ1OlcLimt6RsabuTk/YT9vfWq0wScS+d+K
WwI+T2VCWeG/PheF/sFC2q9jGYm7SDAwERL98qldGEpLXCAbZkFtmZcfcA/fCfl7
5KTKGEJFWwPkBK+DNJXVuf/pm7G6v/hpdRqphSgG027D/NHkvtLJd38webAm66nQ
Y4x0BOEAPMs9ebHgvFES3+cwm0J3OCu6g7DSqUrU/qovsHbb8UTmL0j02xsen0ch
gRJbuXCCsIHf2JZgLJ2k36kRfi9FbXy+49PCJovE0iwoZ9zzt3Ddw6K3KBvNQAI8
RojsNvkdIWRmeZN0E/SA
=FjFS
-END PGP SIGNATURE-

-- 
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/20190108153723.GT8269%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: how to fix this problem using 2.1.3 version

[Michal Petrucha]

On Mon, Nov 26, 2018 at 04:34:42PM +0200, Yavin Aalto Arba wrote:
> It's kinda all over the place.
> 
> 1. conventions:
> urlpatterns is a list not a tuple
> 2.
> 'restaurants.views',  without include? what's this for?
> 
> 3. You did not close the parenthesis correctly in the second item, here's
> how its supposed to be written:
> 
> path('',ListView.as_view(model=Food,
> template_name='restaurants/index.html',  name='index'))
> 
> 
> 4.you are using path and instead of path_re

5. You should either escape the backslashes in your regular
   expressions, or use raw string literals.

-- 
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/20181126144236.GL8269%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: how to fix this problem using 2.1.3 version

[Michal Petrucha]

On Mon, Nov 26, 2018 at 02:48:25PM -0800, Abba Haruna wrote:
> # from django.conf.urls import patterns, url
> from django.conf.urls.static import static
> from django.views.generic import ListView
> from restaurants.models import Food
> from django.conf import settings
> 
> urlpatterns = ('restaurants.views',
> path('',ListView.as_view(model=Food, template_name='restaurants/index.html',
> name='index'),

You've got an unclosed parenthesis on the line above.

> path('food/(?Pfood_id\d+)/',
> 'choose_town', name='choose_town'),
> path('food/(?Pfood_id\d+)/town/(?Ptown_id\d+)/',
> 'choose_restaurant',
> name='choose_restaurant'),
> path('rest/(?Prest_id\d+)/',
> 'restaurant',
> name='restaurant'),
> path('(?Prest_id\d+)/vote/',
> 'vote',
> name='vote'),
> )
> 
> 
> if settings.DEBUG:
> urlpatterns += patterns('',
> ('media/(?P.*)',
> 'django.views.static.serve',
> {'document_root': settings.MEDIA_ROOT}))
> 
> On Mon, Nov 26, 2018 at 5:47 AM Yavin Aalto Arba 
> wrote:
> 
> > did you import settings?
> >
> > On Mon, 26 Nov 2018 at 15:34, Abba Haruna  wrote:
> >
> >> if settings.DEBUG:
> >> # urlpatterns += patterns('',
> >> # ('media/(?P.*)',
> >> # 'django.views.static.serve',
> >> # {'document_root': settings.MEDIA_ROOT}))
> >>
> >>
> >>
> >> this is the result
> >>
> >>  File "C:\Users\Abba\Desktop\rest_picker\restaurants\urls.py", line 22
> >> if settings.DEBUG:
> >>  ^
> >> SyntaxError: invalid syntax
> >>
> >>
> >> --
> >> 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/9f08ad47-6d28-44ef-ba8c-7bfbb9aca8be%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/syLm4GpiFqg/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 https://groups.google.com/group/django-users.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/django-users/CA%2B%2Be-ZX%3DkfFRPBe_edkvQg1vD3F89FUrHfQ-JOKpR793zHS4qA%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/CAL67j7Gk5G0FKfMK3P7NX2PfrS7C_-88GE-5nRUm%2BtURcLtBqw%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/20181126135324.GK8269%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Update profile on login

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Fri, Nov 09, 2018 at 08:32:28AM -0800, pastrufazio wrote:
> Il giorno venerdì 9 novembre 2018 11:37:23 UTC+1, Michal Petrucha ha 
> scritto:
> 
> Found it. :) The error lies in the filter() call: 
> >
> > Thank you very much. I fixed it using  
> 
> @receiver(user_logged_in, sender=User)
> def user_logged_in_callback(sender, user, request, **kwargs):
> Profile.objects.filter(user=user).exclude(date_activation__isnull=False
> ).update(date_activation=datetime.now())
> 
>  
> 
> > By the way, I suggest that you use django.utils.timezone.now() instead 
> > of datetime.now; it's usually a good idea to use timezone-aware 
> > timestamps. And side note, you need to call the function; 
> >
> I will try it out, thanks.
> 
> QuerySet.update doesn't accept callables. 
> >
> Sorry, what does it mean? 

Callables in Python are objects that you can call – typically a
function, but it can also be some other object that defines __call__.

Here I was just pointing out that your original code was
“.update(date_activation=datetime.now)”, meaning that you were passing
the function datetime.now to update, rather than the result of calling
it, and that wouldn't work. However, I can see that you fixed that in
your updated code, so nothing to see here. ;)

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJb6W/oAAoJEHA7T/IPM/klaRUP/3Jwvq9cCzzFL40pnZAZeGON
OeMxriJOnvLa/P3AiAa4cuUhqMmOnJDdWMGsozxVcY3QH7cQ0DgUVu1zl+ZZv0gj
ErPFzARvRaRhvfaYB01BhDRyj06Sgbufe20JmKqQDaUqo1ZcFEG4bEloq2Lp/Y6W
RcPLM/2Q4zH8AjfYD0F/RXFs4ktLVZ2esoOWtW8sqwFHAdOnB3hj1Kb1p8hPm5WD
ZZHrDkRajL/o0f1D29qQVXKoByQktWk0Gg47syztc1+CsdwmxDA6uwruHtajwILg
pQ84HnDy9YjoE1EAM9/DchjfrccrzZVUhtZtshAAvvEL90NpqDawepv+9Y2y6XZS
qS1cG0FTTyoRlVNBmSGbB1CxXy+26vFKKz56seorOUWS0vJ6OwoawMtngkoVEzU8
k8HDZ9iVbmtuY9TsjoDPfpfJJlZAEO45cay3Hu0Bm5ianon37sauagvS8RlHPSuB
V74hvySKLuaxHx0BShX+tHfOsXetFj+yEnNOCzKAps/Q1NlCE9NaHE43AmtUMlL/
+3LEM5LScg1HdGFufIsALf0cZi5hFCxEOoMFFGtcNETgw4Xhd+XAbqxf1a8EmhUT
gbTyS1aTrYhGr2ubpzIa5dE6UhlTsPA2AeAZCBt2DGvV8Ai7SvC7v6oYWGzPJFRX
8Ld48aT5Aa7U0NugUghn
=UII/
-END PGP SIGNATURE-

-- 
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/20181112121953.GD8269%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Update profile on login

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Found it. :) The error lies in the filter() call:

> @receiver(user_logged_in, sender=User)
> def user_logged_in_callback(sender, user, request, **kwargs):
> Profile.objects.filter(user=User).update(date_activation=datetime.now)

You're passing in the User class as the argument, rather than the
instance.

By the way, I suggest that you use django.utils.timezone.now() instead
of datetime.now; it's usually a good idea to use timezone-aware
timestamps. And side note, you need to call the function;
QuerySet.update doesn't accept callables.

Cheers,

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJb5WMVAAoJEHA7T/IPM/klwgkQAJpdDsTNeCFKnmcDpmXPs+S7
vQy+aEyaV3VkfgCpH92n/3Csvad5Fw4cloSef+4DIR1897Hj2x7ga8HA7chcPdJ5
g/mZQNti54ILJMOnWAISD5jPlikec9eibfs06PPSdJnz5O3fcN1hPAy5klWNyEDd
nL4u9IXqWeo8RtkPjKxLzm/im7QWLXYxPGtHnvQHpqHNQGvH0txfLHjUtCUvFV75
ZLPXDO1WUuVsX5T+JEJaLYy9L9TivE5QPwszBdG5pCVd3wJEgLgnkiWxLCbIKRNH
2+M+WQpQfJ2QgA9mOrxWXQaUQB/j8BNyJ1QqW/9F81TDzFjX4i4RIUy6myXrGTnY
l0yDE0O6tD3creuGYGmh9hJXXi/BWq39mkB/dCBSuHzA0qMc65g1UIS8plVCchMK
9djJwpwMo4uuWaQImUrN5d8lSlNDo7Hk5S4lGcGOyiAbuZ9qoSLDSRB0WFVouStW
3XU/9TU5u5FB/ay/oaZGE41V5y4NLpLNFQBtTowX6DQ2sj4d8H9xdFrms6mnwaJ3
+TPSalWERJ/oHGWp9or1kM+4/fYhku47ByteLcLWJM5sG+nF8omt+te+h5l/rVS9
COW8eFfAoMA2pf1ulIlpymEr8XsDJMAnJDF/5lo8GbDoo0g0IpIn0IzxB8KNqzAp
AUb68j4udCCpBCkgOZPB
=80IM
-END PGP SIGNATURE-

-- 
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/20181109103605.GC8269%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Update profile on login

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, Nov 08, 2018 at 09:17:30AM -0800, pastrufazio wrote:
> 
> Hi all,
> 
> I'm trying to update the field "date_activation" the first time a user log 
> in.
> 
> This is the error I get when i try to run the code below
> 
> *TypeError at /admin/login/ int() argument must be a string, a bytes-like 
> object or a number, not 'ModelBase'*
> 
> Any help would be really appreciated!

Hi,

Could you please post the full stack trace rather than just the final
error message? That would make it easier to help you.

Cheers,
Michal

> class Profile(models.Model):
> user = models.OneToOneField(User, on_delete=models.CASCADE)
> location = models.CharField(max_length=30, blank=True)
> birth_date = models.DateTimeField(null=True, blank=True)
> date_activation = models.DateTimeField(null=True, blank=True)
> 
> 
> @receiver(post_save, sender=User)
> def create_user_profile(sender, instance, created, **kwargs):
> if created:
> Profile.objects.create(user=instance)
> 
> @receiver(post_save, sender=User)
> def save_user_profile(sender, instance, **kwargs):
> instance.profile.save()
> 
> @receiver(user_logged_in, sender=User)
> def user_logged_in_callback(sender, user, request, **kwargs):
> Profile.objects.filter(user=User).update(date_activation=datetime.now)
> 
> 
> 
> -- 
> 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/237c6adf-1d2c-4ce7-b8d6-60a7d827833a%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJb5VMbAAoJEHA7T/IPM/kl5AcP/jhCQmT9cJrOFyb36ABIz/+0
/7rcsAq5NCyUAi6g/R4tchDI5K0Yw7uW5LSHl9eDeph1EhCeg/7ZXj8l7z45s5bG
NxR8usfqic/N8gZHPpHDYjnMG/ZjimuiGVQLq8hBA4lRrhvtHv8/VchLuI8U8h23
vez5lu3D8tGDYhBVcMgagji+8to3QmAfc2XYcJVwjgzF/lVyFAxfEzEurVuOshec
GjYYzd/nd8ZNFcZKSNNlh/P7OIW4tmZQ9dheRUV05a9zoG1ETTMEoTk2wy9wawzb
WcvG21Vz2CynnJcooWcJqHDV0bG6CPJgeJqefvZZI+8Fuok2ZgND3JlhsrH89f/R
+MthbLc49DgY1wAOZqMTk31v8I6/+3HV+X69Xu5dnyLwBkT9yY9pdKGmeNyWkatc
xHsnvyHdQi/EBLNTWlyfqv4EPuLoYpYgZJloecrtVhNFxFj+p9IFChwplNHHD566
b7iAlZnhnkhFIfk4oAN7wBGtTqA7rlaVaMWzOPgRIcXj9HYW4k62eOIANjDBER5n
HTdaE63MmPnF/hO6Gl0P45fG+FjMiSwy5erXViyIUjv9j70YQ28IwdRBJCkMaKjZ
SJk+MtxFXnWMdK5CGqDpXjhlriUMMAm+TUL3Iz1mkM3JmXM59l95Njy0mw5jjz6l
xjHIhdIztIG/8kKN567n
=i1zJ
-END PGP SIGNATURE-

-- 
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/20181109092756.GB8269%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Need help with CDN on Django App using heroku

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, Oct 22, 2018 at 08:38:25AM -0700, Akash Purandare wrote:
> I am trying to serve both static and media files on Heroku by using an S3 
> bucket, but I do not know how to properly configure the settings.py for the 
> same.
> Does anyone know how to do it? If you do, please direct me to the correct 
> set of information.

Django itself does not ship with built-in support for S3, you'll have
to use a third-party package for that. django-storages appears to be a
popular one, I suggest that you start here:
https://django-storages.readthedocs.io/en/latest/backends/amazon-S3.html

Good luck,

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJbze/JAAoJEHA7T/IPM/klbT8QAOLnyQUXGiJWWyXk0p1bEDMN
cECp9OkfvZsugvSkubXJF1RppLS9dv4CaPoC2dplC/HjPJeE/4hTtdvZHzHfE/8Y
aFI6ga/grMNvoNFl2F1Khxcau75ZwrJhzWwCQGQDfTnbz4hzjJ9er9asv4IO30X7
+WCGJAg2yLi+GxVEuDM4zC8+7SUzPlVVEL3DsbL6M0UzbcYbWWlZ7laQne3H+BM1
6hQ7nr/u9eYUB3wFVYGbcbtXW1yzSUo/KrW/Xu2Ns3oyhubboDDVr/IsRsRuMwLm
FFkthwS9A2ej37rR1BpQl0ayEOPpsnxNCf3eSytRwfpvxGZkE67kg6qJJdwWaTX+
cteyG8q31LJ2HCpUuFaEUc4YA8D35mGt/4sWfYxXJwDBQ+s4StbhjK3Y/aRYwjdk
oM+ewO/dxm1OQzHWU/a0qcvS8GXAiwIB8AbrsxYwYKPsPqPgx5KDojshuxEH5+X7
kZ7nQZGj7mYRtGkEGjpH/9gaQP6yiVrmORixb6l0vcWLyemmgrC5uIMSfceMpwTH
bUcjyXUfsrOD23ugrv+OKOAYzmce+fHujmEuLe/gy7w4jxWLax+qknf/2MZIcnFV
AXLmRt/hkElTAKnxj8Af+vLtJR20wcrE1rrtt8V4EvxUjKf5yMZgmd7NKw9Bp8Sz
GWuOPu4mWyx1+1sVxzXS
=xJut
-END PGP SIGNATURE-

-- 
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/20181022154202.GP18928%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Using Primary key in two fields

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, Oct 16, 2018 at 10:55:48PM -0700, Rakhee Menon wrote:
> Hi Everyone,
> 
> I have a scenario where one field needs to be a primary key and another 
> field needs to be an AutoFieldand Autofield requires a condition 
> primary_key = true
> 
> I get this error 
> django_reports.MstCompositionFm.makeid: (fields.E100) AutoFields must set 
> primary_key=True.
> django_reports.MstSalarystructure: (models.E026) The model cannot have more 
> than one field with 'primary_key=True'
> 
> This is my case:
> 
> icatid = models.BigIntegerField(db_column='ICatID', primary_key=True)
> makedate = models.DateTimeField(db_column='MakeDate') 
> revdate = models.DateTimeField(db_column='RevDate', blank=True, null=True) 
> makeid = models.BigAutoField(db_column='MakeId', primary_key=False)
> 
> It would be of great help if anyone could figure out whats the solution

Hi Rakhee,

By definition, there may only be one primary key per table – primary
key is the unique key that has been chosen as the primary, all other
unique keys are secondary. AutoFields have a requirement that if they
are present in a table, they have to be the primary key of that table,
because that's how auto-increment columns work in certain databases.

What exactly is it that you're after? Do you just want both icatid and
makeid to be unique? If so, set primary_key=True on the AutoField, and
for icatid, just use unique=True instead. That will tell the database
that icatid is a secondary key.

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJbxyMqAAoJEHA7T/IPM/klo8AP/i83PGOzi7+rwqc566VqdYT9
DY5SF9Vh/NAhCAxNVaC369yXRr2/L2EE0T3mDe9hMv/fSbSp00D25kFwsdLDC5TA
+tIzLN53777mAWFzTIjRhzQuc8usNRvHNcsbfJsaurbX1vm/EObdfjtnTlUzK2z2
KwieFMdbpLOicM7YDHGAGj/wF341blFhu0uDyeHQ6rcrEytaAtcMfPLEE92Ts3YR
qpxGPUwzAbhLOV5xcMsPgT6lnqE8JNxnBjA6DAqxoVk02c2tDoqEiPb71VvPzKdC
OEDxlN4veDSBciuP/ngNHG3kKL7EB5Ce60lo4pAPABhxx8YB6SVJ5gisP6s69j0w
xodELja8zVcrNi0uE0LgnvwS64XG1U5vPSSX6HJzZhozPP2aoP+NZEWcV94IX51O
4BfjWFn45LKLGy+/KENlgvPKMoKSYd9tuTcDFKDmLDb62JIq2ylCFUfj5kdxdZSO
8uMf9ZexQ9Gz604Hbl/xDneUV8k/xu5yfrHk6BX0YRtBxtqIF8E8ZYviqagp2Dw2
Z/zdNSMIGD+j3VxaY7ixGwcHq2svHY/g6AiqUXlA4NuM6KGLO+aWRcjlErryp4gL
q5Kuz5+4UCczpj/qKuNym/6t7BKn51pzX97gZghIVM9A2R5guOW30TB5PCJvgzDN
nOR2s5TXmuVEUdfiOU7d
=D1aU
-END PGP SIGNATURE-

-- 
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/20181017115522.GO18928%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Form Code getting executed during django project startup

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Fri, Oct 12, 2018 at 12:52:31AM -0700, Web Architect wrote:
> Hi,
> 
> We are using Django for our ecommerce site. 
> 
> I have some confusion on when the code gets executed in Django. I have a 
> django form with a choice field in module m1.py:
> 
> class SomeForm(forms.Form):
> field = forms.ChoiceField(choices=get_choices())

The problem is here – you're calling get_choices, and passing the
result to the ChoiceField as a static list. If you pass get_choices as
a function, it will be called at runtime, whenever the form is
instantiated:

class SomeForm(forms.Form):
field = forms.ChoiceField(choices=get_choices)

Good luck,

Michal

> 
> 
> def get_choices():
> return some choices
> 
> 
> In views.py, I have imported SomeForm:
> 
> from app.m1 import SomeForm
> 
> class SomeFormView(Formview):
> form = SomeForm
> ...rest of the view code
> 
> 
> When I run the django project using ./manage.py runserver, I am surprised 
> to see that get_choices gets executed. This is undesirable as I can have a 
> Django queryset in get_choices and I do not want unnecessary DB access. 
> 
> It would be really helpful if someone can shed some light on the above and 
> tell me what exactly is happening. How can I avoid get_choices getting 
> executed during django start  or running? get_choices should only get 
> executed when SomeFormView is accessed.
> 
> Thanks.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJbwFaVAAoJEHA7T/IPM/klm44QAJMjeGXjs7fzHaCpi7Sn16Ib
bHAyoluqmS5+Pw9yYsg3FaYJwx1JC6r/vB6Hv9WfBAI5cIzJa+k0e8T7PkuUg3Nc
ioG4izJWYC8F4MSXXynRVrt8UR4OfQrDw2tmXPXI++nf9GgMmN1Q/VJwVyWKUK8h
MD6L8ap0IIhhjOr3Nwvc1lsT68Hx4eEBmPcGa88FsHMUpox6ktIYmIeCq9WDIVQz
GKxMdRr+SUjcq7NeqqLL1davlL2YIKAaSdy1tNaxQ890u436MUkQ0L5FK2FtpKIh
ViqraEi/BaHWzZ6Dr6l6oG5QlrIHiG89VjYvYYo6qAtB67Yl5A6QnLY1YkMpiNkv
jZJt+u3ad4+qP5JQ0/SDYruyN2cjt6SVowQmAAxyGYbzFYMhWEz/NDopPXB/8q01
nr7o+N4azH696Ryr9bH5KEilrZvoxxxt9Zb+IGaJU5tfHs4A2Pzmw6aNmwMkRAVg
Mo0eaQuOu4zG6ix5X2wX7z+2MrGfBw0OJisOH3BzPOQ9CdHOaB0HuaveKQ39aVCL
vmGgPy+NnBr+EL/r1PC+sD9JjSFM6sD8+7fB1rvEtYsILj+DHHICYOZGaBGU34zm
TJjCHDSTp5Dx/p5mrt8Y9UJLf5U7C2Sz562R2ez3wKkrCqxGKN7fY7cq0oB01Cph
geJsa6+RNjRHpCbM1U/U
=7eA9
-END PGP SIGNATURE-

-- 
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/20181012080854.GL18928%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Alternatives to using __contains?

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, Oct 10, 2018 at 03:06:20AM -0700, megaman wrote:
> You mentioned SQLAlchemy. Does SQLAlchemy use actual functions/methods over 
> magic strings to perform the operations?

SQLAlchemy uses operator overloading and function calls in Python to
write SQL expressions, yes. If you're interested in details, you can
look at the docs:
https://docs.sqlalchemy.org/en/latest/orm/query.html#sqlalchemy.orm.query.Query.filter

> If so, are we even able to swap out the Django ORM and use SQLAlchemy?

Of course, you could decide to not use Django's ORM, and instead use
SQLAlchemy, but if you do that, you also lose Django's migrations,
model forms, almost all of django.contrib, all the neat test isolation
features in django.test, and that's just the things that I can name
off the top of my head. I don't think it's a trade-off worth doing if
your only reason is that you don't like the kwargs-based API of
relationships, expressions, and filters.

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJbvgpYAAoJEHA7T/IPM/klaZkP+wTJ+l3p+DPN/KJPAabMKf95
llom243U4TJ1DhWjr/Ca6PrkseCU7ZKN6EY/oCXIy6fGLNHNsRm31HOA5MpHn0PP
2CwcylVr7Gkss7Pt1sz0ighzHSeB48rlKSoqA2YjYF6krP2UV/JtX1ubDmnw8L3q
HFEhE5tvl93uZPVUnGlsmIcfd2RWupTeZGiBdfvFNeQX04tUYbsfN9YpZy6OpnHC
Fq8yZRSiRnxRARNQjB3YqKCn5Vkcj4xx2fFhe82aeVzhXFblK76QxgPRCEV6fl5t
s0FORX3AggxApYmACTN4I3rC7XAHdayM9/BuMesP2eLQurAmXvx4UyPnpAbh8nRn
La0oZQcXjGzlb2qzxeBU575Zy869rvZmcVahXEyETYXkPSfjgoIMOVG+xNQoZ2oJ
XIhIQyxuCMUR/0UYwibNU+1XygmDLIGZl2dUEkau4yRTUJnr0PC8uXX/Kxmd7KBo
68YdqyOB9spYCyQOWMgUpPGXV33nTFqX2V/b2QsFMUc4QhK5AMNIPkDCYoMxd4vS
CJd6jaA++u4kpzurlclSqP4/anTGtF/YSJ1IMEcK+/JGL/GezkM8h3jFS5DnTzOz
BgpwHeAjFWteACZ8xuJmWpOJxEtbkrzJUE1HEp0jERE1WyJQfNN3M+KSodJwbIJk
QV+X8TdvkIvmUx6wkPFU
=GVrx
-END PGP SIGNATURE-

-- 
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/20181010141904.GI18928%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: how to create, read, update and delete other dependent tables in detail view Django

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, Oct 10, 2018 at 06:32:52AM -0700, django_learner wrote:
> Hi everyone
> I have three tables 
> class Employee(models.Model):
>   name = models.CharField()
> 
> class Dependent(models.Model):
>   employee_id = models.Foreignkey(Employee , on_delete= models.CASCADE)
>   dependent_name = models.CharField()
> 
> class Document(models.Model):
>   employee_id = models.Foreignkey(Employee , on_delete= models.CASCADE)
>document_name= models.CharField()
> 
> So, in the employee Detailview I want to perform CRUD operations on 
> Dependent and Document table
> 
> Pls can anyone provide th solution
> 
> Thankyou

I suggest that you start here:
https://docs.djangoproject.com/en/2.1/topics/forms/modelforms/#inline-formsets

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJbvgL/AAoJEHA7T/IPM/klGbMP/An0WiaasGjW15c37OdYbh2X
2Lf3slT4Au24CuTD0XAD4bGcYoCBQP69tdwTbxNt50Tld1e0KEuJQ5OTrcjM4njr
y+U/OpktVbkstHDcVMrYOhFpnK8Rm53jKfbJykH2Wgfnb74RsaKZ1a75R62EucQJ
UZmag03Rps6DIaqKP+ctLcXZh0JqfHGsQ0vzO/EgZyye+F4Z2EtD8fyvzB0uSBgN
YIKxw7+j8PmbSgVrOVEMrHtoFhDp/98Y5TPven7K+RK0+ZfuZHnHsZ7XRCV8S9vp
p0dfS3+xo3pbtSceQwi8kl6emynyw3FpjgEHv0szNbu2OUY5wRk4xpVUFuKEDmI4
Fd2GtFKKF+sneCY0qxirSiyEJF84cQnLOYssdp9pVaJTtQxkNhal8QrWlWiZW0TG
s3jdio9IJDh95orsyApxgkhNNcPOzEVCH7GK9voVgkzwL0sTOhQfOazOnXJ/4Mw5
qgGJcyiEQwuJO50UJwtxb4ZSF+CGn3DH/9DMu8e9aaxPgTB7vg4dBpEuoPsy/IUU
HMZtpVXP3gRIxLCUJTe/RZIjIjC4sDS4GcX+AL+x+Vvnp9LVlhNYoNhe7XbQkLVl
Q0k/0GdiJT58evMEKX57wf/6j/cAL1shl3YybDhEbpfsqSHwctjdDb5l/XB2dhml
naDJ+rv9kE4lliiZMiFi
=Mu2J
-END PGP SIGNATURE-

-- 
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/20181010134743.GG18928%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Alternatives to using __contains?

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

On Tue, Oct 09, 2018 at 08:03:27AM -0700, megaman wrote:
> I’m pretty new to Django. I have just learnt that could filter a
> query set this way: 
> 
> Questions.objects.filter(question_text__contains=‘what’)
> 
> This kind of scares me a little because the filter “contains” is
> actually part of the field name. And I guess there are other
> operators appended to a field with the same __operation pattern.
> 
> Wouldn’t this make refactoring tricky? Even renaming the field name
> has to be done carefully. In my mind, this feels messy. 
> 
> Is there an alternative to doing this? Something like:
> Questions.objects.filter(question_text.contains=‘what’)
> Or using “contains” as a function?

The syntax that you suggested here, unfortunately, is not valid
Python. In an argument list, you can use either positional arguments,
which are either Python expressions, or keyword arguments, but those
require a valid Python identifier to be on the left side, which
“question_text.contains” is not.

> Basically, can I do the same thing without adding “magic strings” to
> field names?

Not at the moment, sorry.

The idea of using a style more similar to SQLAlchemy has been floated
on the dev mailing list in the past (as in, years ago), but I cannot
even find the right thread at the moment, and I'm not aware of any
recent developments in this direction.

All in all, chaining relationships, expressions, and filters with __
in keyword arguments is how this is done in Django, and it's most
likely going to stay that way for the foreseeable future.

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJbvb0CAAoJEHA7T/IPM/klndQP/Rd91q/4ANlPzkIzzJd3xRuX
xrJgvFnWNnv9tZdQK1kwaoQPRG2Msx9taahg2NPvVMQUNKbsMKW60dctmtUMpXVC
MXrWscLEwXecV94Zp10x9JFPJCMLjNvDELvWjkLIMz7/j/Ih4h5FnzfHTiwlg4DK
2XkGiuBaXVM+TKST8RI1w7YphvcjfdehQzy1wRx8wS5FoqgrBjxJ4FJJojDYeo5s
MO0kfPLzPHg4QIU6eYwg2euSmACUorkrXVj0q1Qr8b5AsAkVCPVIM7ryapGrorp4
6EZ+97FMwemoCAtkWzL6jSvnnp87Mm/587BzxRTOJ0ff2pkUv5wjizTmED5/Hur9
fmjz4CpuVx2wHsvt0ty4gNyQ693h2J1kRZxenP0iFAnzipRPy/Lll46uxB3MhX5P
uHjM+gqk6RvHfFh4H/jBe2mh2WSEKtpCPG5kRp3v/cw6qgV16CeQDk60u8Vlymqk
SXj0FGj9W/HGytVt11+tGKX0fPcnDyy4GF5CIRBVTfviq/yz+GZQcO1Dd2VoAaMc
fAwLpKsPNQrTnJBZXPSby/bgYTYljyIBl6YOe9heL4yCocQVEO6zQRmZ81hCzB4H
9DoMiW6Y7oILcm7L/DC8DY/if2aLyxSN4Rnl05yPZnAmiatIMxssW5rWrz4+7YiS
iH62Ro8wxl48vrSxC7Hu
=gsXH
-END PGP SIGNATURE-

-- 
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/20181010084907.GF18928%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Django 2.1.1 creating CharField in a Form in Django on a Raspberry pi

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

On Tue, Oct 09, 2018 at 02:28:25PM +0200, konstantin Heinrich wrote:
> I replaced code with {{ form }} but nothing changed.?

There's one more error in your code, and it's right here:

> return  render(request, 'base.html',  {' form ': frm} )

As you can see above, you're passing a context variable by the name of
“ form ” with a leading an trailing space to the template engine. As
far as I know, context variables cannot contain spaces, because there
is no way to actually refer to them from the template itself.
Honestly, I'm surprised that doesn't raise an error.

Regardless, you should remove the spaces around “form”, and then
you'll be able to refer to the form as, well, “form” in your template.

Good luck,

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJbvKE4AAoJEHA7T/IPM/klQToP/0+5qNMWutLRDIkvYdXAz/iQ
rTfPg36VcKJzgdHz2ncRvl9wYNhxyeyGqYS/FjQr8ZyqkMFsL89UfamSEDdwkJiP
BOVm4IWrVdPoANRqtaklmChBHMbFCAsDrj+RY6UH9nZDTb5yiKraRHfKNFadJ4GA
LimrIXMbcPJ/2hzC+imv68qsR81WOeIdSSNrY4TnyJrzVp0qgZaiWdQ8YCmG0Tbc
S71nNvUUfbNCp2kCiu/pH0wLscMXBJlSVJ5BtzGN99gK9LusSUKWJ/mqLm7w9DCS
k2Z0xCgQ8NwaNRvtkRsl3TEHIpAfac3vf92/VEuWsOGWpCb8d8KYCwVzsf57J9Kf
6QCP9pw9RP8B3JMIm3I0djiakA3UTZNfbog3aQGzLVROmuQjUyWwvxVw2vaqUhj2
moL/Eq/M6eahcfYn3CFYfLojqukXDS0pL1Qgj+Njqng2qiG5DKAIF1iMFZZoREs4
OOZC+dJg3Vos/ebY/vZBYdAxO92UsKYXod5WCqNaoyyKuwWaufoHhNZoteVZ5hjj
F6GGcGP6ugdswmZDT1E3+RnLgFsmB8G8+w3uAi8obFDhFjkldgfVxEnw0Ki2JcTB
UWkD1KCur9f7hYo+34vNNfiCtXlxACaMdVNdb3X1R5aCMvh5VjvBJI/31ja6Yw9Z
K3cucs2jnkLdbf9KiSZD
=aClS
-END PGP SIGNATURE-

-- 
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/20181009123816.GE18928%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: "No such table" error, with different tablename as in query

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, Oct 08, 2018 at 10:29:30AM -0400, Michel Lavoie wrote:
> Hi Matthew,
> 
> Thank you for the suggestion, but as I mentioned the error is not limited
> to my views.py; it's also present in the auto generated admin page.
> Basically in the example I gave, I call the delete() method from my
> transaction object, by id.
> 
> There's also the "main."prefix in the error that bothers me, in addition to
> the "s" at the end of the table name. But I'm sure that it doesn't come
> from my views.py, this error appeared after upgrading to 2.1. My app's code
> is on GitHub: https://github.com/miek770/huitcent/tree/master/finance
> 
> Thanks,
> 
> Michel

Hi Michel,

I also took a glance, and didn't find anything suspicious. Is there a
chance that you have multiple databases defined in your settings, and
a router that directs write queries for the Transaction model to the
wrong one?

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJbu3YYAAoJEHA7T/IPM/klrZ8P/1FAI/sm5UEMOUSnxjLM6fI+
/9Lu7/7ZhFvKFVXOSa6GT2pxEjOkdLmtmMwQv1ghvxgvCmVMEohOKoNDPDwhdEGA
VvYuBD7rNhmBqPTwGYdn2ci4fFIK3EaaMuv5pBkdW/ztWcyFgZaJFA1T8KEYR+nR
/8ZBcZOhcZAGpdqppCIZoJTPsHcRggAt2CGWvNzFC9BxFh3w+BqTfTkBLfa2ZQpg
MmBEpqu5VGsOIG3nlULnvnzBMhJEy8IkGf8TTmp0MUeRUycnRQnsCfIVjqDfQuGo
aetk6Jdb9C9760STJnPp7FAdtQqIYj8vdy0NU2KoM9hhxZk80YOuC1PCqDkteuRH
SmkwH5kI5FZKiKAeDUPBn4h2hvkMm/5B1kqtk+BzzAZPCY5CRkmJno+BjCWb0nFE
zSOA/i01a4hlEbhBNDjeYyxvuVVigGGXYBfLuuagIGz/61axu/pWn18sGElRqr+r
0T0c63QxuOtj6ZCJ5HrtMDRfzfnAjrRImqxmviQJo10XRKSsLavRYqIuKC1AgKFq
K+2c6cel4wb+n698FEAK24ic7gYR+ZH5kX0qOEXUMB2ND5DMKBKaqdkr7S3EqgIm
7KiuM/oL8SCxAdKKzJvvZyLwSgoDQxcAWng6YccWIZk5C5gcJHwI0wljjfPP0U3v
pUFCfu/sRN9umoHyryiF
=8Eai
-END PGP SIGNATURE-

-- 
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/20181008152200.GD18928%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Not Able to Connect to Vertica

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, Oct 04, 2018 at 06:24:27AM -0700, ankit...@axxonet.net wrote:
> Hi all,
> 
> I am trying to connect Django to Vertica, but I am not able to get any 
> useful documentation for the same. Whatever links I am getting don't help!
> I have attached the screenshot of the errors I am getting . I have 
> installed the ODBC driver for Vertica and  I don't know what to put in the 
> Settings.py-> Database -> Engine field
> These links are not useful , but these are the only links I am getting on 
> the internet- 
> 1) https://github.com/shayh/django-vertica
> 2) https://github.com/rutube/django_vertica_backend
> Please help me out with the "Engine" field that indicates the django 
> backend, as I have configured all the other things and  I am stuck at this 
> thing.
> 
> Thanks in Advance.
> Ankita

As far as I can see, the first of those packages is really old (>6
years), so it's pretty much guaranteed that it won't work with any
reasonably recent version of Django. The second one also seems to be
unmaintained since 2016, and it doesn't even claim to have full ORM
support anyway.

All in all, it doesn't seem to be feasible to use a Vertica database
with Django at this point, at least not with open-source libraries. 

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJbth25AAoJEHA7T/IPM/klkOcP/A5tInkEz2L42/TRPpZ6tRnO
kI+aln8rKnMsO4GuadwEAgvL2xs3kyasFno2AK2Y2oCwOHlfRwLEVLnUG0kHKD3U
DuzZHTukaLuU5NDACcYaDD2sRh63Tce1z/20qqI6WneidoP8GysEvzOxOJPbrWOQ
NWhUYmoSDtRMdyz9dn0cWEwrFpOyJQaiRv2VGdtH0xvF2YaNkgB+qb/ORnd2GAqv
0/K6f3L02Ldq41/5o9SgV3Fi8T/ATybokfvjRSkPFq/p+wApgoz+RrllMvco11+T
lPkEK48uQ7Sy1HHpmeyA6WtKNvBhjrDMYtaZPZ7MvdVAn/QiCwZLB+b7v7zf9OsA
vqcd7WGO2B81pG11dhvuywjXlK4Hl9CVZ+XWPRlT7r9UUU0WkKv2jQdMroTW4Rrz
MqE1rSh04Hu/Yj0TSFNy0VGjyWTgk2+TZBIBACcIRxJJwQqtA09zukDJMboW0N2d
nenxtLK5RCsfeBnHNdubUk03UCztDZwGleTbyqtZ9mA6feQPeI7HsTo2i2yGyc/M
JEj8PjJV/OIM1Frc6nCwEEnP4ZAxmBYjNR02MtgVuM11MrrCXUmjZJOqb4iGX3x5
ZPGvSaVjkmCOZiIOF91tKJFREr13le7z0JnbeH8SWLDxk4AuciVBMZr7oXwpcj5/
uqgpXk7dP4KsyX/n3TH4
=kOAa
-END PGP SIGNATURE-

-- 
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/20181004140338.GA18928%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Running a single version of my Django app but with two databases: one for dev and one for prod

[Michal Petrucha]

On Mon, Sep 24, 2018 at 03:18:46PM -0700, jim_rain wrote:
> Hi, 
> 
> I'm developing a Django app, it's hosted on an EC2 instance so I'm using 
> wsgi, even in development. I would like to create a production and a 
> development version where really the only things that are different are the 
> two databases. I want the code to be the same on both. I figured I could 
> just have two settings files and two wsgi.py files so it's set up like this:
> 
> wsgi_prod.py:
> 
> *import os*
> 
> *from django.core.wsgi import get_wsgi_application*
> 
> *os.environ.setdefault("DJANGO_SETTINGS_MODULE", 
> "canzare.settings.production")*
> 
> *application = get_wsgi_application()*
> 
> 
> wsgi_dev.py:
> 
> 
> *import os*
> 
> *from django.core.wsgi import get_wsgi_application*
> 
> *os.environ.setdefault("DJANGO_SETTINGS_MODULE", 
> "canzare.settings.development")*
> 
> *application = get_wsgi_application()*
> 
> 
> Then in my httpd.conf I have these lines:
> 
> 
> *WSGIScriptAlias /dev /home/canzare/work_area/canzare/canzare/wsgi_dev.py*
> 
> *WSGIScriptAlias / /home/canzare/work_area/canzare/canzare/wsgi_prod.py*
> 
> 
> The only real difference in the settings.py files is that they point to two 
> different databases in mysql. 
> 
> 
> This sort of works, I can access the production site with / and I 
> can access the development site with /dev/
> 
> 
> But then everything falls apart. The admin site on both seems to be broken. 
> It looks ok but if I try to perform any actions it tries to make me 
> re-login. 
> 
> 
> Also (and this may be the root of the other problem) I don't think 
> migration works correctly. I can migrate to one instance but not the other. 
> 
> 
> Has anybody come across something like this before and/or and I'm going 
> about this completely wrong and is there a better way?

First, regarding management commands, of course, if you have different
WSGI applications using different settings, you need to match your
management commands to those as well. So if you want to migrate the
production database, you need to run the migrate management command
with DJANGO_SETTINGS_MODULE pointing to the production settings, and
likewise for the development environment.

Second, just using different databases might not be enough, at the
very least, another obvious thing you'd probably want to isolate is
media storage, not to mention caches, and what have you.

Third, the issue with cookies is because you presumably use the same
cookie name for the session cookie for both deployments, so they
overwrite each others' session IDs. While you can fix this by setting
a custom name for the session cookie in one of the settings modules,
you're likely to encounter such conflicts for any other cookies that
you might use, too.

Oh, and it's likely that a lot of links from your deployment sitting
at the /dev/ prefix will point to URLs sitting in the production
deployment, unless you're extra careful with making sure that all
links include the script prefix.

All in all, your approach seems like it's more trouble than it's
worth, and you'll make your life a lot easier if you just make two
separate deployments sitting on separate domains. (A relatively common
approach is to use a “dev.” or “staging.” or “beta.” subdomain of your
main domain for the dev/testing/staging environment.)

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 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/20181003080839.GA1181%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Geodjango Error

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, Oct 01, 2018 at 03:02:18PM -0700, vaibhav.gupta_c...@gla.ac.in wrote:
> I have installed PROJ4, GDAL and GEOS libraries using OSGeo4W installer 
> . But the problem is with GDAL library. 
> Earlier there was an error showing :-
> django.core.exceptions.ImproperlyConfigured: Could not find the GDAL 
> library (tried "gdal202", "gdal201", "gdal20", "gdal111", "gdal110", 
> "gdal19"). Is GDAL installed? If it is, try setting GDAL_LIBRARY_PATH in 
> your settings.
> 
> Then after setting the path using GDAL_LIBRARY_PATH = 
> '/home/sue/local/lib/libgdal.so'  in settings.py file the error changes to 
> what I have stated before which is :-
> OSError: [WinError 126] The specified module could not be found.

If you used '/home/sue/local/lib/libgdal.so', then that would be
incorrect – you write that you're trying to run this on Windows, but
this is a Unix path, so of course Python won't find that file there.

Replace that with the full path to your GDAL DLL, and if you use
backslashes as a directory delimiter, make sure to either use a raw
string literal (r'c:\path\to\my\gdal.dll'), or double-backslashes
('c:\\path\\to\\my\\gdal.dll').

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJbsxTVAAoJEHA7T/IPM/klLA0QANjRJZjywvglG74qJQujhyK3
F0FkcN6RVXlwZv2XBq21NufpItQ5kWwnPWEFfA0LwCfIIqrwbsQu2Al1r6xaq29U
uq7cgZDNCfvfMrqnG7sVoqddkJN9taIkl0z+KQtaqg1rsfTdNZa6esKBc062+rCO
HhqrAbHZaUaYkenfvMXp1Qe3GBN6taJ+5banbBoWs1ipeUYK3v+ltLkv8sN4ipHg
Fcj5FKHv1ldt2pE88JvVwGxcrW6cpngKjElZZTjgTDGokC2v7kptCVkkj3KJWPNv
VR+OK0FWwsJdF2uZ3eni9v/MNBTCMe1b8m/ZM6tU2aWW3+8EqznMaX82I+8RMOtS
dPwvTk5To7DwVhm6tQtaO1+abdf/pZ6X76hWwusGbmbCW/Mn04S66CMM+TgVGhSX
LyQZajgYKq6qyt6C/YkNO1wkGNNY8eaDVSotdRMXd9oDpg9xVwx2jwVuGRMBhsVi
2Oou19GTU9GLfOLAC3pEGU3/724ZfLBWP+dCksHtTLrRqU0u9KhEtbrLUrutfDUG
rdWxpmKMjkwyZ7oZt4kLu+ZTEuu2tYU4G770Vq3Z4Ui1HbBYX0QNIEiwhTXehx+a
3vNZ0I5M9idu9kfgrPFmthYb69eWi2cZuPbOMoC1lBm0JrVE5v8L4NwEKx0Itp7u
i/QDsOX/rzuTUQyvnOq3
=VilN
-END PGP SIGNATURE-

-- 
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/20181002064854.GZ1181%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Refer tutorials to make multitenant application with shared database with multiple schma

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, Sep 19, 2018 at 12:09:20AM -0700, Devender Kumar wrote:
> Hi,
> I need a help from you I wanna start a project which is a multitenant 
> application and I want the tenant can register themselves and schema is 
> created for him from the shared database across tenants.
> I want to make this application in Django I know all the terminology of how 
> multitenancy can be achieved I just want to how to write the code for this 
> as I have never played with schemas and other stuff.
> You refer to any project where I can get an insight, Any tutorial link for 
> this project. 
> Thanks 
> Dev

I don't have any tutorials at hand, I only know that the de-facto
standard implementation of schema-based multitenancy is
https://github.com/tomturner/django-tenants, but AFAIK, that only
supports Postgres. Not sure if there's anything like that for mysql.

Good luck,

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJbojg9AAoJEHA7T/IPM/kljwwP/0kKZ3CwgUl9OxNB2THxcQEJ
ioDPkLIiF6HLRHhnBo29wZJX+2ngrh1lMagUZLJ7FpnPCl6IUyf1hmE4WyRU17fn
93ypqt2HLgz5HFKtvcRO5tGIQUf7BGa/J6NZHTgZy6QhYVqILgdUrjLQYcCq6Vj3
POHfVOjQv2VznnQ58ZPBkn9RHBRkVjcYHEJ5Pqm88PkJOvDF+0CefQaSeWwQemxX
p59WJKWFyLg/Fn/MJ2r8tZsc8Le/HtzUzh18ACUUT6cxsbrg3EW69/KMNaATvNjW
Ls6lALBEACTZR+qyC1H78fT/EaOGIei3PaxjDKJh1S4D2dDJUpWTvN+YCBXiXhk5
bTy1u/OJabkdhW9bDTV2hTF4zwQtiywqfjcesuBPhDWPUhOXiwQ0DV5E4CtLo3Nq
ZUNNBQCVqiUr9678kFBiA35pGTkZ964qAjwPNyhRk+/Rg2LhbxUNVTJYbTXTz/tO
nb21Sl8IIsepXdws8p7sWUHdbUB2bfoNvINuYEKSYFtbWaexyTmIP7iUmfEO66pz
W7IYOafwHzdC47nM90BaeDqhSYsncc+7yranMDjsrMxz9OCLrWntxGGXg0fXhNj8
/4o4SLkUjACV94K/VoAyr1ZisOGmlWqro+j/4jaJErFFZ2cb2asqBGAdv37NuWRe
bICVowQe52Uq42z+oS9J
=P8xi
-END PGP SIGNATURE-

-- 
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/20180919115125.GY1181%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Recreate all tables in mysql after dropping the database

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Joel,

On Sun, Sep 16, 2018 at 10:16:42PM +0530, Joel Mathew wrote:
> I tried to fix mysql problems in my database by dropping tables. When that
> didnt work, I dropped the database.
> I then recreated the database, and tried to run makemigrations. But I am
> getting errors about missing tables:
> 
> joel@hp:~/myappointments$ python3 manage.py makemigrations

[…]

>   File "/home/joel/myappointments/appointments/forms.py", line 68, in
> 
> class AddAppointmentFormReadOnly(forms.Form):
>   File "/home/joel/myappointments/appointments/forms.py", line 70, in
> AddAppointmentFormReadOnly
> for doc in doctor.objects.all():

[…]

> 
> How can I remove all database data and revert as if to a fresh database.
> I have tried a rm -rf myappointments/appointments/migrations/*
> 
> On django 2.1, ubuntu

The immediate problem that you're facing here is that your application
is making database queries while it is being imported – see line 70 in
/home/joel/myappointments/appointments/forms.py. You will need to
rewrite your forms (and any other classes) in such a way that they do
not query the database while they are being imported, for example by
making use of ModelChoiceFields, or generating any dynamic choices in
your views, and/or forms' __init__. Otherwise, if you keep hitting the
database on import, it will be pretty much impossible for you to set
up your application in an environment where the database schema does
not already match your model definitions.

Second, you should treat your migrations as any other code, because
that's what they are. Treat makemigrations as just a helper to give
you a starting point when writing migrations, rather than as a magic
silver bullet to fix all database problems, and once you have a
migration that does what you want it to do, commit it into the
revision history of your code base.

Good luck,

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJbn1kHAAoJEHA7T/IPM/klAxQQAIRjUj2R5XFOO0Q457AX0mWA
BM05wwLHEqxR0KxGkkV6M/6IN2qkhD0Sg9AJLTjQBvmKB+0OH85RrOHem85JaoCW
3H0vhgukM5yDIcZYNUDephAj6pvjR0gAFmVWPW9PY8+5hHBTkFLLwEAMvL96uNdO
TVerrRNcDw7QeiihyHa23JPEP9sYd3g9GEH8gtwJQ1q68oGOaNkEbESK8kQIv5hq
Zu1Dlf01h+dJzZNaKjvMlZJlNsuQNkPxpiuus5mKv/EFWLyIbwqS9r/Uy15NLTo9
Lg5dLi9mSPr6yDiNI24u/WFQI//YyRIOKc7w6d0DRKPBR7NP3Xw8h7DYOGCpwJns
xkgw0wqsdRw7Wjblao3TLCcgaYRe11B6YkyxwYMFo0rL/foT9NYD5OCxNwZjmgs/
9paC8Ye8SDzamza78WEL9EIBkGjzSUSqgHvBwlMjiHXAEXRDMaFM/vbz+Cb3YFAR
jEa5LLgBXrfjcVxE+pROBsB+jfgONTo+M9Y/4Xw3WiuDiYxF8FQGBqr3QLcMfIyp
4KoHqAN04/yvFtXbZNs7097fNLfi0vhYjRLPqp/HDqYOvS/LIlnHkJ/EJBHK0CqQ
RRRpS42Sin6Mqoz3XyGOxQFfU3fxUl/lBnwdKAB3IrrOPZQvf7Uw03+CCflOeYFZ
8Ksm4yD3EHXidQCYkeDN
=Uc5m
-END PGP SIGNATURE-

-- 
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/20180917073432.GX1181%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Contributing to Django

[Michal Petrucha]

On Fri, Sep 07, 2018 at 11:36:27AM +0530, Sanjeev Singh wrote:
> Thank you for replying me back Sir, It will be great help for me if you can
> provide me some links where I should go for that, how I can jump into this.
> Thank you.

Hi Sanjeev,

Really cool that you want to get involved! I'd suggest that a good
place to start would be
https://docs.djangoproject.com/en/2.1/internals/contributing/

Cheers,

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 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/20180907065646.GW1181%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Trying to replace a char field with a forgein key feild

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, Aug 27, 2018 at 09:37:03AM -0700, mattstroud via Django users wrote:
> So when we started the database, it was good enough to have a char field 
> with choices. But as time progressed I need to convert that field to a 
> foreign key field. The follow I'm trying to take is such:
> 
> 
>1. rename  to tmp_
>2. create a new field with 
>3. have a RunPython fill the data for 
>4. delete field tmp_
> 
> I can get steps 1 through 3 to work with out issue. But once I remove the 
> old field from the code, the migration breaks because the field no longer 
> exists (which makes sense). I'm curious if there is a way to work around 
> this, because my googling is coming up empty.

I'm not following – why would the migration break? What part of it
would break, and how? None of what you wrote suggests that this should
in any way fail, as long as operations 1, 2, and 4 are performed with
AlterField, AddField, and RemoveField, and you use model classes
passed into RunPython through the ``apps`` argument.

Could you perhaps provide some more details about the failure that
you're experiencing?

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJbhoRCAAoJEHA7T/IPM/klbKAQAJrCF9WNMOOsaWc3V/5PzNN3
quKafkPijxOkSl3AlLcPE6Os/2gPAc7rQZ+jKIorkXP6/RTh1U2DgGzYhLxeEzJL
tcS8cTtfsRx50En7Rbq9MnvQd/3G/xbEPaPzIp7moB1R0z7DY6uJoY39hpeJltd4
D2OVBwtryKs3r98B2PsQuwA5m7i8qy14LzosK1TQUGeUzEwINzaGQdt07aI24hpE
XJtfkUMXk7v8t3OuEPaSNCabfK0bGhV8WYRFj1JKUONrKhTl7RCXXBpmDahH2M5P
zInUKwChxa6zOwCpZ8tgoj2NSB0xlWSBzCZPV6LXiUvy7bPIJ9N64MBbIP9ntsEL
5ozGwE8oSmVpdDAlGY8IdwnJdgJzemRokD1z2PKo4zJViDrDxdOB4dVmrJ/FjrH6
cYe022N8iHHVx9aAtMXyuitfRzcNukpUTiyXPDji3XeUAxjmR3/sezWXiCA0iDua
vc3mytzQldPw2t7E9q0a/Q4QvFAh42ALzpZzZwdVmx81j3CGbbF6GiWuYiL/xYUc
bTt9RsEAFiNiDXWXiljf94ZwDQaAd+sHCwHP+zleHHKQ4n2iAZrb+Cy4vq2uNpGi
hZRAmIgOkqcN4kaD4wnImYigydSVgJ1AtL+MTcIgm8U06uSTicjRs67+RWvmvS6G
bpaFyP2KsdzU58s0sTTA
=LaQQ
-END PGP SIGNATURE-

-- 
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/20180829113220.GV1181%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: How to delete least recently used not expired django sessions?

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Fri, Aug 17, 2018 at 05:44:22AM -0700, Web Architect wrote:
> Hi,
> 
> We are using persistent django sessions for our website where in the 
> session information is stored in MySQL. Over last couple of years, the 
> session data has grown to a huge number and we were planning to clean it up.
> I know that there is a django management command 'clearsessions' and we are 
> using the same as a daily cronjob.
> But our challenge is we have long expiry timelines of like 100 years so 
> that our users are never logged out (unless they clear their cookies etc). 
> Hence, the clearsessions won't help. 
> 
> The solution we are looking for are removing the sessions which are never 
> used for a long period. Let's say a user never came to our site for 3 
> months after last logging in. We would like to purge those sessions. Would 
> really appreciate if anyone could suggest any such solution - be it in 
> Django or if we need to custom build it.
> 
> Thanks.

There is another de-facto standard solution to this problem, which
does not involve setting the session expiry to years – it's usually
referred to as “persistent authentication cookie”. That way, sessions
would expire after the usual short period of time, and it also makes
the persistent login feature optional for your users.

I haven't found a maintained package that would implement this for
Django applications, but you can find a bunch of material on this
topic. For example, this article seems to consider a lot of potential
attack vectors:
https://paragonie.com/blog/2015/04/secure-authentication-php-with-long-term-persistence#title.2

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJben3lAAoJEHA7T/IPM/klRiMQAKnoqOWIrbQDiDcaARde9jl+
SuPfHZP/H44t7z610+CC2D03C4hps+7acQWslH2S+WFL/+VUJPqytGTWsAJbs12A
/R+UaIlwDGFMeRBw2xdDusZtbE4t+atGS5PPgr8hEW89/op9/DruSed1cVxoUiBp
pwNwBst+cieNhtBYpXBUCe8mRxRegc8xCz/pKRw9ZycszYgB4rTpDVwOFMmxPWuS
rKDRgMsXhYQskiGWi5oSHQ8xEgxBeGXdv3HnlwCm9TenXs1gfVQwbRhG4btivCUD
nzhpUTtHx3PP5/uDK0GM87MqB6ufuf7H/7QXgFKTWBZxSeOXwaxICsxYaG54DMld
hYxFk36RtjufWgcffQooBfw3eavtzAnPdjlZzEI3ZYj5fPx9agGJf177JAVSCovS
bppF1QbipuIfQlLyv7gee8bR6a6uLEQZ4vp9NHrfqWjXYqmIDxubnVB5B1/d6yvG
S9liRlkoGAWC9tTS5ig03QV1b4nBlJIonKIRBecrfJXHw3G2WojY8HAiSyyz9A4P
S/XcvOzK7dWsw/NUmx84GkR3SGfFeQor3bVWUeBhG6BBOjZq6cj+MHa2gZswIIYa
d6dHRCa4hyDwBLZDaEbI4EDbIkrY82L87PD9KW+0xbBYojwysQz8pL/3WHc8F1NL
0VXYCCnD/4/LdzywjR21
=njLP
-END PGP SIGNATURE-

-- 
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/20180820083758.GS1181%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Django Generic Date Views

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Gerald,

Couple of points:
- - please try to stick to the mailing list when posting follow-up
  questions or materials rather than replying off-list; this makes it
  possible for other people to jump in and offer their advice (and
  also doesn't send the message that you expect the one person who
  tried to help you to personally coach you through your issue), and
- - rather than attaching your code in a tarball, posting the relevant
  parts of your code in-line typically makes it easier for people to
  help you – I can just look at the email and directly see the code,
  rather than having to fetch the attachment, unpack it, and go
  through all that hassle. (And don't even get me started on the trend
  of posting screenshots of stack traces or even code; some of us are
  reading our mail in text-mode terminals. Get off my lawn, kids! :P )

With that out of the way, let's get back to your questions.

On Thu, Aug 09, 2018 at 09:15:36PM +0800, Gerald Brown wrote:
> Thanks for your info.
> 
> I am attaching my views.py, url.py and index.html.  The index.html creates a
> menu on the main admin page.  I have included some comments there about the
> strange happenings that are going on.  I am not able to include any trace
> info because I have gone back to my original program from before these
> generic date views.
> 
> The URLS1.py file is from my top level and URL.py is from my visit app. In
> the views.py file most of the code is formatting the reportlab pdf file with
> the data from the queryset assigned to various locations in the pdf.

urls.py::

from django.contrib import admin
from django.urls import include, path

#from visit import views # as visit_views
from visit.views import PaymentTodayArchiveView 

urlpatterns = [
path('today/', PaymentTodayArchiveView.as_view, name="today"),
]

urls1.py::

from django.contrib.admin.sites import AdminSite
from django.contrib import admin
from django.urls import path
from django.conf.urls import include, url
#from django.views.generic.dates import DateDetailView

from patient import views as patient_views
from visit import views as visit_views

admin.site.site_header = 'MEDREC Administration'

class DashboardSite(AdminSite):
def get_urls(self):
urls = super(DashboardSite, self).get_urls()
custom_urls = [
path('^$', self.admin_view(HomeView.as_view()), 
name='admin'),
]
del urls[2]
return custom_urls + urls

urlpatterns = [
path('admin/patient/', patient_views.prescription_view),

path('admin/visit/', visit_views.daily_payment_view),

path('admin/', admin.site.urls),
]

views.py::

@staff_member_required
# ~ class PaymentTodayArchiveView(TodayArchiveView):
# ~ queryset = Visit.objects.all()
# ~ date_field = "visit_date"

So, starting from the beginning – the correct way to reference a
generic class-based view in an URL config is to use
MyViewClass.as_view() – note the parentheses. You can see that in
action in the custom AdminSite that you wrote. The parentheses are
missing in your urls.py.

Second, I don't see urls.py being referenced anywhere in urls1.py,
which you say is the root URL config.

Third, your usage of the ``staff_member_required`` decorator is not
correct – I recommend reading the section of the docs which covers
decorating class-based views [1] to learn how to do that. Not to
mention that you left the decorator in place, while you commented out
the view itself, which means the decorator would get applied to the
next definition following it.

I'm not quite sure how I can help you here, since you don't actually
have any code in place that would use the GCBV...

> It seems like all tutorials I try to follow they are only half complete and
> they leave out a lot of stuff..like how to access these views.  Maybe that
> is something I should know, but don't.
> 
> As it is getting late here I will be taking another look at this tomorrow.

Michal

[1]: 
https://docs.djangoproject.com/en/2.1/topics/class-based-views/intro/#decorating-class-based-views
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJbbXEsAAoJEHA7T/IPM/kl410QAM6IM+hMFu7+0n41MysAJebW
qk7LE/YaO5lWeBFtbBnzKuQTQ3cIV102Q2e/YBYLOwh0lmlefD01iqR+pOJLdWAu
/Fbr6uqG5Nlem7hFoc0g6QvQLADej4AqsdGlQ80de12gb66PHvHaAkqV726cPodI
13V8qXsfZsj4ix0XsAZmPEmYKW6PoL4TV2J9FFQYLr8ZqlzD3Y+QkEojtnspfVod
ayK7nH3DcABEU1R0SGx+e/7ifwCFXkk3KjIC4ESRGH7pEaozJZu9onb7YP32Yejd
B9sUA1+7A5Cj1IQvlKc8cDayZ3qLRTV7tOG3oUvy/adiRFoBU1MgTodNJccT5Rrx
+WdEgYeGsmd5rrBZAio0S6fhGuCClRMQiknmFjX4YJ2pN4aBCZo7R8RlmkCkODmw
JgKecTujBLC8ax2EDYH887W/qALIsyk5+J1tOZlDblg3+cYMm8LCGQLUCpz5hARb
z35ZXRjb8f7WY6KN8JXDPvL9oNvypOV+AxmJP6NsYAPufA0RtTvkrTrPdXr0a5VK

Re: Django Generic Date Views

[Michal Petrucha]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, Aug 09, 2018 at 07:54:29PM +0800, Gerald Brown wrote:
> One thing I discovered is that I had the line for the url.py file in my top
> level url.py.  I moved it to myapp/url.p but still same 404 error, however
> no longer get the "has no attribute" error
> 
> How do I call this view?  Tried from the browser
> "http://127.0.0.1:8000/today/; and I get "__init__() takes 1 positional
> argument but 2 were given" error.
> 
> Tried "http://127.0.0.1:8000/visit/today/; and I get 404 error.

I'm afraid you're going to need to provide more detail – how about you
post the full traceback that you're getting?

Also, the question which URL is correct is hard to answer unless you
post all the relevant URL configs.

> In the line "queryset = Visit.objects.all()" won't that select all of the
> records in the database when I only want the records for today which I then
> use to create a reportlab pdf file? Prior to trying to use these generic
> date views I was able to generate the file but only for the current date.

You lost me at the part about reportlab, but ``Visit.objects.all()``
does not actually fetch anything from the database yet. It only
returns a QuerySet that can be processed further (you can add more
filter expressions, set ordering, and whatnot), and only fetches data
if you actually evaluate it (for example by iterating over it).

So you'd typically just set that as the ``queryset`` attribute on a
generic view, and then every time the view is executed, it will take
that unevaluated queryset, add all the necessary filters to only
select items for today, and then fetch those.

Michal
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJbbC7JAAoJEHA7T/IPM/klCh8P/j9iQowdzLeuTNpz5sQpahiU
KhiePgASItMSnKhwFN5Qv++5eV21dl7fViBFPfkQtQ6hNxJXewX8M7kElvr9dmh3
/8GxmkzrW+yuqBgagzNXHOtMi3zvmrFxkiwR6vKcMoTJUR8jsMFnvvkpeCEqFJas
vj7kCbNPJ26GuIWCvFkmtBf2wpd18L49EuPly88nqt+R5tLNNzZ9h9hHzLB8Jr7f
Lq6m397Rxz9oAk/tXw7XFiOB/tIm3jG77XUGYzhv424qEo9a5R1WFOL+s+MoOkdi
wxdb/WEzk9gxf5+v9HtDI3eRYkqaE1WWXQOe7cGTWlDhW/FPXmuI8dSqQOKYbDCL
bNEzcq/bXpIvy0Ot5Ja4RB7OKXBOyd7QElfkF5TTYCyc9JEH8IavwhAtJlL1S6J9
mkzcUjsv9nTqjPqSBBd0bLrNtm5VCyz731w4KvrSHPVTMPJkplkYDWsf1kL6XPEZ
yybYAlMmNF2RA0MelSAjQw3FNAGK2CEXN0Pq+wja3dZs16zv+Y2vhEUhTgFgVmld
KxGmcoULk05UAsbRqboQMBDubfatUxLuGY4MNKARI39T5vLmuzbwkdlv3T0viFVu
OAKIliDdgYP7yUb3uZI1DK1UhgZKxjHTbLt/Es7yGkXFMRYdvJ7pv6TQ69prjrVp
8B5S03RXDeThmAEffLjr
=erht
-END PGP SIGNATURE-

-- 
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/20180809120842.GJ1181%40konk.org.
For more options, visit https://groups.google.com/d/optout.

Re: Django Generic Date Views

[Michal Petrucha]

On Wed, Aug 08, 2018 at 05:42:06AM -0700, Gerald Brown wrote:
> 
> 
> On Wednesday, August 8, 2018 at 8:15:21 PM UTC+8, Jason wrote:
> >
> > what have you tried so far?  What issues are you having with the 
> > documentation examples?
> >
> > "can't get them to work" is really uninformative,  RIGHT.
> >
> 
> What I tried was the TodayArchiveView by following the docs. When I enter 
> http://127.0.0.1:8000/admin/visit/today/ in my browser I get a 404 error
> 
> The code in my views.py file is:
> class PaymentTodayArchiveView(TodayArchiveView):
> vi = Visit.objects.all()
> date_field = "visit_date"
> 
> The code in my URLS.py file is:
> path('today/', PaymentTodayArchiveView, name="today"),
> 
> In the docs is says ".as_view()" should be added to 
> PaymentTodayArchiveView. When I add that I get "AttributeError: 'function' 
> object has no attribute 'as_view'" error.

This exception indicates that you didn't define
PaymentTodayArchiveView as a class, but rather as a function (which is
not consistent with the code you pasted above). As long as
PaymentTodayArchiveView is defined as a subclass of TodayArchiveView,
like in your snippet, you should be able to call ``as_view`` on it.

So yes, using ``PaymentTodayArchiveView.as_view()`` in your URL config
would be correct, as long as the definition of PaymentTodayArchiveView
is correct.

And regarding the name (``queryset`` vs. ``vi``) – the point of using
generic views is that the default implementation of the view supplies
most functionality. Most of the time, you're able to configure what
objects the view operates on by setting certain class attributes in
your customized subclasses. In this case, all of the generic date
views by default look at the ``queryset`` class attribute when they
want to read objects from the database, not ``vi``, which is why you'd
typically use that name in your subclass.

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 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/20180809101435.GI1181%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Model formset not saving

[Michal Petrucha]

On Tue, Jul 17, 2018 at 12:57:21PM -0700, cbpar...@gmail.com wrote:
> Is there a paid support option to get help? I've been trying to ask for 
> help on IRC for a while but all I've gotten is insults.

Reading through the IRC logs, that was a pretty unpleasant exchange,
I'm sorry you were treated like that. As a community, we should do
better.

Anyway, on to your question.

> On Monday, July 16, 2018 at 6:06:00 PM UTC-4, cbpa...@gmail.com wrote:
> >
> > I'm using Django 2.0.3 on Ubuntu 16.04. Any idea what would cause a model 
> > formset to return None when calling save()? Here is the relevant code:
> >
> > RepairFormSet = modelformset_factory(Repair, form=RepairForm, exclude=[])
> >
> > form = RepairFormSet(request.POST)
> >
> > if form.is_valid():
> >   form.save()
> >   return render(request, 'message-loggedin', {
> > 'title': 'Success',
> > 'message': 'A repair request has been made successfully.'
> >   })
> > else:
> >   return render(request, 'message-loggedin', {
> > 'title': 'Error',
> > 'message': format_html(str(form.errors))
> >   })
> >
> >
> > I checked the database and nothing is added to it, form.save()
> > just always returns None. When I try to debug within
> > django/forms/models.py it seems that form.has_changed() always
> > returns False, causing nothing to be saved. However I do not
> > understand why it thinks nothing has been changed. Any help would
> > be greatly appreciated.

Hmm, how do you know that form.save() returns None? Because if the
above is your literal code, then the form.save() call will definitely
return a list – the default implementation of ModelFormSet.save()
always does:
https://github.com/django/django/blob/stable/2.1.x/django/forms/models.py#L657-L669

As for why nothing is created in the database – are you also updating
the management form of the formset on the frontend to indicate that
you have added a new form, and that the formset should process it?

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 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/20180718091500.GG1181%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: how to programmatically get the index name of a model field on a migration of django 1.8

[Michal Petrucha]

On Fri, Jun 29, 2018 at 11:25:16AM -0300, Fabio C. Barrionuevo da Luz wrote:
> Hello, I need to delete an index created automatically by Django, from a
> third-party application and my own django apps, for later I recreate the
> index optimized way.
> 
> this django application is used in several companies.
> so I need to distribute these improvements via django migration.
> 
> 
> I'm using raw sql in a RunPython migration, to delete and create the
> optimized index.
> 
> in django 1.8, there is a deterministic way to I previously know what the
> index name is generated for a given model field or django has a python
> function/method to get this information?

I'm not sure if the names are generated in a predictable way, but my
gut says they probably aren't – at least not in general, maybe for
certain specific DB backends, they will be. (As far as I can see, in
the base backend implementation, Django introspects existing indices
in the database, and finds the name that way.)

If the index is created with db_index=True, unique=true,
index_together, or unique_together, you might be able to get away with
a migration with two operations:
1. delete the index with an AlterField, AlterUniqueTogether, or
   AlterIndexTogether operation, and then
2. use SeparateDatabaseAndState, and in `state_operations`, you undo
   the effect of the previous operation, while in
   `database_operations`, you'd execute your custom SQL to create the
   optimized index.

Another option might be to use a RunPython operation, in which you use
the schema_editor passed in to drop the index with its alter_field,
alter_unique_together, or alter_index_together methods, and then run
your custom SQL. If changing the options of models or fields is not
enough, then you might have to get your hands dirty, and figure out
the name of the index with editor._constraint_names, but then you are
entering private API territory, and things might break on you after
upgrading Django.

Yet another alternative might be to upgrade to a version of Django
that's not past EOL, and use the more explicit support for indices
introduced in 1.11, but I have no idea how much easier it would make
to solve your problem. (You should consider upgrading regardless,
though.)

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 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/20180702110845.GC1181%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: ARGPARSE ERROR

[Michal Petrucha]

On Thu, Apr 12, 2018 at 07:58:08PM +, Ankush Sharma wrote:
> Hi Babatunde ,
> I installed other listed tools ! Here the main concern im talking about is
> Argsparse -
> the Progressbar2 3.6.2 requires argparse, which is not installed.
> Thanks in advance
> Ank

What version of Python are you running this on? Either it's a very old
one (2.6, 3.1), which would be unsupported by pretty much any
reasonably recent Python package, or your Python environment is messed
up somehow, and it lacks a part of the standard library. If the former
is the case, you need to migrate to a newer Python; if the latter,
then you need to fix your Python installation, and make sure that it
includes the entire standard library.

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 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/20180413090646.GN1181%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: single queryset from multiple tables

[Michal Petrucha]

On Fri, Sep 15, 2017 at 07:26:27AM -0700, DG wrote:
> After reading this thread and answers on SO (e.g. How to combine 2 or more 
> querysets in a Django view? 
> )
>  
> I'm still not sure if this code is fully lazy with Django 1.11+ or if it is 
> going to load everything into memory:
> 
> qs1 = Model_A.objects.filter(foofield='foo').order_by('created_at')
> qs2 = Model_B.objects.filter(barfield='bar').order_by('created_at')
> 
> paginator = Paginator(sorted(chain(qs1, qs2),
>  key=lambda i:i.created_at
> ),
>   50)
> 
> 
> If the querysets each referred to 500k results, would this blow up?

Yes.*

* Unless you have a very powerful application server that can hold a
copy of your entire databse in memory, and efficiently process it.

What would happen is that the sorted() builtin function consumes the
entire iterator you pass in, which pulls all the matching results from
qs1, and then qs2, which will build model instances for all of them,
and sorts the combined list in memory. Then you'd be taking the result
of that sorting routine, and pass that to the paginator, which would
discard all but 50 items from the potentially huge list of model
instances.

I don't think there's a way to not do this with the sorting that is
built-in in Python, because it's always eager.

Cheers,

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 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/20170918130933.GP8762%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

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 

Re: Dynamic model, reverse foreign key not working

[Michal Petrucha]

On Tue, Sep 05, 2017 at 04:56:10AM -0700, Roman Akopov wrote:
> Unfortulately, it did not help. I have added "model._meta._expire_cache()" 
> call almost everywhere, before generating dynamic model, after, between 
> steps, it did not help a bit, error is exactly the same.
> Also, I have additionally tested my application against django 1.10 and 
> django 1.9 and got exactly the same result.

On which models did you call that? You should call it on the target
model of any relationship that you create dynamically. So if you have
existing models Target1, and Target2, and create a new model Dynamic
with a ForeignKey(Target1) and ManyToManyField(Target2), you'd need to
call _expire_cache() on Target1 and Target2 right after creating the
dynamic model, but before trying to make any queries using those new
reverse relations.

If this doesn't help, then you might have to investigate if there's
perhaps some cached attribute that doesn't get cleared.

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 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/20170905123820.GL8762%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Dynamic model, reverse foreign key not working

[Michal Petrucha]

On Tue, Sep 05, 2017 at 03:47:37AM -0700, Roman Akopov wrote:
> Hello,
> 
> My problem is very rare so I'll try ad add as much useful detail as 
> possible.
> 
> I am using python 3.5 and 3.6, Django 1.11.4 
> 
> I am creating complex security related application and need to generate 
> additional models based on other applications' models. In general, 
> everything works fine, models are created, migrated without a problem. But 
> there is single problem I totally failed to solve.
> 
> Let's say there is preexisting model Alpha of some other application and I 
> dynamically create model Beta which references Alpha with ForeignKey. The 
> problem is that Beta does not get reverse relation, so I can query for 
> beta.alpha, but not for alpha.betas. I receive 
> "django.core.exceptions.FieldError: Cannot resolve keyword 'betas' into 
> field. Choices are: x, y, z"

So the deal is that each model's _meta caches a bunch of structures
storing the list of fields, reverse relations, and so on, the first
time you access any of them. If you add a new field (or a new reverse
relation) after those caches have already been filled, the new field
or relation won't be reflected in them, leading to errors just like
yours.

There's an internal undocumented API that takes care of this,
Model._meta._expire_cache(), which will clear all those caches. It
should do the trick for you, but as always with private APIs, be aware
that it might break or change in the future.

Cheers,

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 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/20170905113641.GK8762%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: ValueError: Need 2 values to unpack in for loop; got 3 (actually num_loopvars = 2 and len_item = 3)

[Michal Petrucha]

On Mon, Jul 17, 2017 at 03:46:30PM +0200, Ogi Vranesic wrote:
> Hi
> 
> I have used some templates in older django versions.
> But now in django 1.11 using the same templates, the error:
> 
> ValueError: Need 2 values to unpack in for loop; got 3.
> 
> will be raised on line 207 in module django.template.defaulttags
> by the method render of class ForNode
> 
> Actually is by me looking at code *num_loopvars = 2* and *len_item = 3*.
> 
> After I've outcommented this part of code, some of this template as a form
> is displayed and one can work on it.
> 
> So could somebody tell me what is purpose of this two variables and
> comparing of them?
> 
> Thanks very much in advance and best regards
> Ogi

Sounds like you are trying to loop over a list in your template,
something like this::

{% for a, b in mylist %}
...
{% endfor %}

The problem is that mylist contains triples, not pairs. It would help
a lot if you could show the actual template code, as well as the
context that you pass to the template.

Cheers,

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 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/20170717140802.GD23772%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Possible bug - Incorrect escaping in Django SQL query

[Michal Petrucha]

On Thu, Jun 01, 2017 at 02:29:17AM -0700, Roshan Raghupathy wrote:
> Hi,
> I came across an issue yesterday. Post on stackoverflow 
> 
> 
> On further investigation today, I think I found the source of the issue. 
> It's this line 
> .
>  
> The parameters which are escaped here are never reverted back to the 
> original form.
> I tested a dirty fix by converting all '%%s' to '%s' and the query worked. 
> Should I submit a bug? Has it been submitted already?

Hi Roshan,

I just took a quick look, and it seems you are right – in all of the
official backend implementations, the *_trunc_sql only use the second
argument in the right-hand side of string formatting, so this
double-percent escaping appears to be wrong there.

I did a quick search through the issue tracker, and didn't find
anything about this issue, would you mind submitting a new bug report?
It would be best if you could include a complete minimal example that
we could easily run to reproduce the problem.

Thanks,

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 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/20170602091343.GR23772%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Generating HDF5 and downloading

[Michal Petrucha]

On Fri, Apr 28, 2017 at 03:38:36PM -0700, avill...@ucsc.edu wrote:
> Hi everybody, 
> 
> I've successfully gotten a web app that takes user data, uses that to make 
> a query, and the outputs a CSV file. However, what I'd really like is to 
> output an HDF5 file. I googled around and there doesn't seem to be any 
> documentation on outputting an HD5F file from a Django web app. I tried 
> adapting the Django example of outputting a PDF (
> https://docs.djangoproject.com/en/1.10/howto/outputting-pdf/) like this,
> 
> 
> I'm making a website using the Django framework. I've successfully gotten a 
> web app that takes user data, uses that to make a query, and the outputs a 
> CSV file. However, what I'd really like is to output an HDF5 file. I 
> googled around and there doesn't seem to be any documentation on outputting 
> an HD5F file from a Django web app. I tried adapting the Django example of 
> outputting a PDF (
> https://docs.djangoproject.com/en/1.10/howto/outputting-pdf/) like this,
> 
> response = HttpResponse(content_type='application/hdf5')
> response['Content-Disposition'] = 'attachment; filename="test.hdf5"'
> 
> h = h5py.File(response)
> h.create_dataset('Name', data=test[0].name)
> 
> 
> but I get the following error, 
> 
> 'HttpResponse' object has no attribute 'encode'
> 
> 
> So I guess I'm misunderstanding how to use content_type in Django's 
> HttpResponse. Does anybody have any experience with outputting HDF5 files 
> form a Django web app or could help clarify how I might adapt the 
> HttpResponse to work with HDF5?

Hi,

I've never personally used h5py, but at least from the docs [1] it
looks like it only supports writing output to real files in the local
filesystem, not into any file-like object. From a cursory look, the
documentation seems to imply that all file operations are performed by
low-level C code that doesn't know a thing about Python, which makes
it hard to support file-like Python objects.

According to the docs, the “core” file driver with backing_store=False
might do the trick, but I don't see how you could then read the byte
stream of the in-memory file afterwards. Barring that, you'll need to
create a temporary file (for example with the tempfile module [2]),
write the HDF5 file there, read it into the response, and finally
delete the temporary file.

Good luck,

Michal

[1]: http://docs.h5py.org/en/latest/high/file.html#File
[2]: https://docs.python.org/3/library/tempfile.html

-- 
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/20170502082822.GB23772%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: First models.py needs tuning

[Michal Petrucha]

Hi Rich,

On Fri, Apr 21, 2017 at 05:48:01AM -0700, Rich Shepard wrote:
>   What about my other question? When I want to limit acceptable strings in a
> data entry field to a provided list, as in postgres's check constraint? Is
> Mike's suggestion of clean() the way to handle these?

As far as I know, there's no way to declare CHECK constraints in your
model definitions, at least not with vanilla Django. However, you can
still add those constraints in your migrations using RunSQL.

Anyway, that only takes care of database-level enforcement of such
constraints; however, if any of them get violated, you'll just get an
integrity error from the database. If you want to be able to
gracefully handle violations of those constraints, and produce more
meaningful error messages (for example, when validating a form that
processes one of these models), you'd also implement those checks in
Python, either in your models' clean methods, or if it's a constraint
only involving a single field, you can also just add a custom
validator to that field.

On Fri, Apr 21, 2017 at 09:41:05AM -0700, Rich Shepard wrote:
>   I'll let Django do this. However, should I still specify unique_together()
> for the columns that would have comprised the PK?

Indeed – if you want to be certain that those natural keys are really
keys, you should list them in unique_together. That will enforce
uniqueness both with UNIQUE constraints in the table definition, as
well as higher-level validation in Python.

Cheers,

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 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/20170421215001.GW23772%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: First models.py needs tuning

[Michal Petrucha]

On Tue, Apr 18, 2017 at 03:13:24PM -0700, Rich Shepard wrote:
>   Converting from the postgres schema to a Django models.py for my first
> Django project. Most of the syntax (64 lines in the file) should be correct,
> but there are two conditions that I have not found how to handle.
> 
>   First, a couple of classes have primary keys with three fields. I know
> there's a models.PrimaryKey but haven't found an example of how to apply
> that to a field that foreign key fields.

I have bad news for you – Django does not at this point in time have
support for multi-column primary keys. A large part of the ORM is
built around the assumption that each model instance is identified by
a single field acting as its primary key.

A lot of time and effort has been spent trying to implement them, but
it's a huge project, and it's not even close to being ready to get
merged. As far as I know, nobody is currently even actively working on
this feature. If you're interested, look up composite fields in the
archives of django-developers@.

For the foreseeable future, though, I'd strongly recommend that you
save yourself a lot of trouble, and just add a surrogate primary key
field to all your tables and models.

Cheers,

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 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/20170421085007.GV23772%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Let's Encrypt installation fails with WSGI on Ubuntu 14 LTS

[Michal Petrucha]

On Fri, Mar 24, 2017 at 03:22:40PM -0700, Moreplavec wrote:
> I'm trying to install SSL certificate with Let's encrypt on my VPS running 
> Apache + WSGI. 
> 
> I'm following guide: 
> https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-ubuntu-14-04
> 
> It works fine for all PHP sites, but i get an error when trying to install 
> SSL for Django app. I think the problem is, that SSL cert conf is made as 
> duplicate or currect conf file, so apache configtest fails and whole 
> instalation is reverted:
> 
> command: *certbot-auto --apache -d django.my-domain.cz*

Personally I'd recommend that you move away from the automagic
features of certbot that mess around with your config files, and just
configure your webserver manually to serve ACME challenges, and
otherwise fall back to whatever it is supposed to do (like proxy to
your application server), and use certbot in its webroot mode which
just puts the correct file in a location of your choice without any
config changes of anything.

With nginx, the correct arcane incantation would be to use something
like

root /var/www/acme;
try_files $uri @wsgi_upstream;

I'm pretty sure you can create an equivalent configuration with apache
somehow, maybe using mod_rewrite or something.

The advantage of using a static configuration like this, rather than
letting certbot change the httpd config on each run, is that there are
fewer moving parts, there's no risk that the config automagic won't
work with the config directives used in your particular config,
there's no need to reload the webserver on each run, and in general, I
personally distrust any magic that messes with my configuration.

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 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/20170325213403.GH23772%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: How to keep track of online users?

[Michal Petrucha]

On Fri, Mar 03, 2017 at 01:19:18AM +0100, Melvyn Sopacua wrote:
> On Thursday 02 March 2017 14:47:30 Branko Zivanovic wrote:
> > I need to know online status for each user. How do I do that?
> 
> from importlib import import_module
> from django.conf import settings
> from django.contrib.auth import get_user_model
> 
> engine = import_module(settings.SESSION_ENGINE)
> # docs[1] 
> store = engine.SessionStore()
> store.clear_expired()
> logged_in = []
> User = get_user_model()
> 
> for session in store.model.objects.all():
>   decoded = store.decode(session.session_data)
>   if '_auth_user_id' in decoded:
>   try:
>   user = 
> User.objects.get(id=decoded['_auth_user_id']
>   logged_in.append(user)
>   except user.DoesNotExist:
>   pass
> 
> Of course, since by default the session length is 2 weeks, this doesn't tell 
> you much, 
> so if you want true "online status" you'd need to use your own session store 
> to store 
> the additional "last_online" field and middleware to update it automatically. 
> Code 
> above contains ample hints for you to start digging.

Keep in mind that this will only work if you use a model-based session
storage; if you use a storage like the signed_cookies session backend,
this will not be possible.

Cheers,

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 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/20170303082823.GB23772%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Django Migrations?

[Michal Petrucha]

On Wed, Mar 01, 2017 at 07:45:24PM -0500, Ed Sutherland wrote:
> The problem surrounded a textfield that had no default. I added the
> default string and migrate complained it was an int. I changed the
> string and migrate still complains of the int default that no longer
> exists.

Hi Ed,

When trying to get help with an error, it's usually helpful to post
the full traceback that you get when it happens. Otherwise people have
to do a lot of guessing as to what could have gone wrong, and it just
takes longer to get all the relevant information out of the question
asker.

In this case (and now I'm just guessing, because you haven't provided
a lot of detail in your problem description), it might be that you
have a broken migration in your repository that you'll need to fix. If
that is the case, could you also post the code of the migration file
that is failing?

Cheers,

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 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/20170302094550.GA23772%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: "TemplateDoesNotExist at /"

[Michal Petrucha]

On Sat, Feb 25, 2017 at 01:20:49PM -0800, Richard Belew wrote:
> "TemplateDoesNotExist at /"
> 
> (full trace log at http://dpaste.com/3XZ8H3C)
> 
> this must be near the top of django newby issues, but i'm stumped
> on the simplest example i can generate:
> 
> i've used the `settings.TEMPLATES.DIRS` variable to specify a
> shared templates directory (also to simplify things), and
> am using an application's `views.py` file to anchor a
> named url, but the django engine still cannot find the `index.html` file
> i've put there.
> 
> what am i missing?  any hints appreciated,  Rik

[...]

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

This appears to be the incorrect line – here, you set 'DIRS' to a list
containing a single item, which is a tuple containing a path. The
problem is that you wrap the path twice. Django only expects a simple
list of paths, so if you just drop the tuple wrapping the path, you
should be fine::

'DIRS': [os.path.join(BASE_DIR, 'templates')],

> * djggApp/views.py
> 
>def index(request):
> template = loader.get_template('index.html')
> context = Context({})
> return HttpResponse(template.render(context))

This is not strictly related to your problem, but I would strongly
advise not to render templates used as HTTP responses in this way.
Instead, you should be using either the render shortcut [1], or
TemplateResponse [2]. They are mostly equivalent, and both accomplish
the same thing as the above code, only with a single function call.
More often than not, less code is better.

Also, unlike TemplateResponse and render, the code above will not
apply context processors, unless you change that Context to a
RequestContext, which is something that's super easy to forget, and
I've actually seen people get bitten by that in the past, and spend a
lot of time trying to figure out why their templates are not behaving.

Cheers,

Michal

[1]: https://docs.djangoproject.com/en/1.10/topics/http/shortcuts/#render
[2]: 
https://docs.djangoproject.com/en/1.10/ref/template-response/#templateresponse-objects

-- 
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/20170225222908.GW23772%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Difference

[Michal Petrucha]

On Wed, Feb 15, 2017 at 12:48:21PM -0800, Luvpreet Singh wrote:
> What is the difference between realted_name and related_query_name ??

One is used as the name of the related manager on the remote side, the
other is used to traverse the relationship in queryset filters from
the remote side.

Let me try to illustrate that with an example.


class Reporter(models.Model):
name = models.TextField()


class Article(models.Model):
reporter = models.ForeignKey(Reporter, related_name="articles",
 related_query_name="articles_written")
title = models.TextField()


So, when you have an instance of the Reporter model, you'd use the
related_name, which is “articles” here, to get a list of articles:

r = Reporter.objects.last()
r.articles.all()

However, if you want to get all reporters, who have written articles
with titles beginning with the letter “T”, you'd use the
related_query_name in the queryset filter:

Reporter.objects.filter(articles_written__title__startswith="T")

Does this make it more clear?

Cheers,

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 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/20170216065000.GR23772%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Django allauth, manage redirect

[Michal Petrucha]

On Tue, Feb 07, 2017 at 01:30:18AM -0800, Branko Zivanovic wrote:
> Thanks for the answer.
> This will redirect user after every single login, right?
> I wan't it to be after firsty login only, so people can update their 
> profile. I want this to be done only once.

Not exactly what you're asking for, but one option might be to define
a custom “get_login_redirect_url” method as described in the docs [1],
and check either based on the account creation timestamp, or maybe add
another field to your model that will indicate whether the user has
already completed that step of the sign-up process or not.

Good luck,

Michal


[1]: 
https://django-allauth.readthedocs.io/en/latest/advanced.html#custom-redirects

-- 
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/20170207095023.GF23772%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Separator between forms in formset factory

[Michal Petrucha]

On Sat, Jan 28, 2017 at 04:33:47AM -0800, Jeroen van Oorschot wrote:
> Hi,
> I'm using a 
> modelformset_factory()
> 
> for displaying a form multiple times automatically. This works perfect.
> 
> I would like to have some kind of separator between the individual forms in 
> the page. Now the formsetfactory just shows all forms after eachother, and 
> it can be quite hard too see which input belongs to which form.
> 
> Does anyone have an idea how to make this? If not, i'd like to request it 
> as a feature on the formset_factory 
> 
> .
> 
> Kind regards,
> Jeroen

Hi Jeroen,

Have you considered simply iterating over the individual forms in your
template, and including the separator in the for loop? You can find
some examples in the docs [1].

Good luck,

Michal


[1]: 
https://docs.djangoproject.com/en/1.10/topics/forms/formsets/#using-a-formset-in-views-and-templates

-- 
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/20170128163659.GA23772%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Am I stupid or is there an essential error in Django 1.10 Docs?

[Michal Petrucha]

On Mon, Jan 16, 2017 at 12:23:09PM -0800, 'Peter Müller' via Django users wrote:
> Am Montag, 16. Januar 2017 21:20:53 UTC+1 schrieb Daniel Roseman:
> > The traceback shows that you are importing your views module in the 
> > __init__.py of your app. Don't do that. 
> 
> Well else python doesn't find the view.py file?

Python will be able to import db_testing.views just fine even if you
don't import viewsi from . in db_testing/__init__.py. All Python cares
about is that there is a correct Python file in the correct location.

If you're interested in more details about what's going wrong here,
there's an explanation here:
https://docs.djangoproject.com/en/1.10/ref/applications/#how-applications-are-loaded

In particular, the following paragraphs:

> At this stage, your code shouldn’t import any models!
>
> In other words, your applications’ root packages and the modules
> that define your application configuration classes shouldn’t import
> any models, even indirectly.

What's happening here is that the root of your “db_testing” package
(i.e. db_testing/__init__.py) indirectly imports models, because it
imports the views module, which in turn imports models.

Just removing the “from . import views” line should let you move
forward – unless you also have other imports in the __init__.py file,
in which case you can most likely just remove them, too. In general,
in an average Django package, there's little reason to import stuff in
its root package.

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 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/20170117070025.GN1628%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: models foreign key

[Michal Petrucha]

On Thu, Jan 12, 2017 at 01:40:43AM -0800, jeffreyequizuvero wrote:
> 
> 
> *This is about the models foreign key, I have two tables and i used foreign 
> key to connect these tables however after i did migration it's not working. 
> Is there any wrong with my code? *

I can see that you have a commented-out “managed = False” in the
definition of your models. Did you create and apply migrations before,
or after you commented the attribute out? If you ran your migrations
with managed = False, then it's expected that those tables are ignored
for migrations.

If that's not it, then I'm afraid you'll have to provide more details
than “it's not working” – what steps did you take exactly, what was
the output, what output did you expect, etc.

Good luck,

Michal

> *please help, Thanks. *
> 
> 
> class *Author*(models.Model):
> *Author_code = models.CharField(max_length=50,unique=True)*
> Author_Fname = models.CharField(max_length=30, blank=True, null=True)
> Author_Mname = models.CharField(max_length=30, blank=True, null=True)
> Author_Lname = models.CharField(max_length=30, blank=True, null=True)
> 
> class Meta:
> # managed = False
> db_table = 'Author'
> 
> 
> class *Book*(models.Model):
> 
> Book_code = models.CharField(max_length=50, blank=True, 
> default=user_code_key,unique=True)
> *Author_code = models.ForeignKey(Author, to_field=Author_code', 
> on_delete=models.CASCADE)*
> Book_title = models.CharField(max_length=50, blank=True, null=True)
> 
> class Meta:
>  #   managed = False
> db_table = 'Book'
> 
> 
> 
> 
> -- 
> 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/f8a12da9-8983-4375-b7ff-fa631d4522a0%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/20170116064111.GM1628%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Dynamic Models

[Michal Petrucha]

On Wed, Jan 04, 2017 at 06:38:54PM -0200, Guilherme Leal wrote:
> Is there a way to populate Django model cache on the fly?
> I was thinking about saving the model definition on some backend (database
> for instance) and loading as needed. This way we can basically build a
> custom admin interface for the model definitions, and load the models
> (through "type()" or something similar) into the cache "on the fly".
> 
> Guilherme Leal

Hi Guilherme,

I kinda got lost deeper in the reply chain in this thread, but
regarding the original question, have you had a look at
https://djangopackages.org/grids/g/dynamic-models/ ? django-mutant, in
particular, seems to be quite close to what you're asking for. Even if
it's not a direct solution for you, you might be able to take a lot of
inspiration from there.

However, keep in mind that any kind of dynamic runtime model
registration involves heavy usage of Django internals, which means it
will be fragile, and likely to break with each new minor release of
Django. Also, there are many parts of the ORM that kind of just assume
that models are static throughout the lifetime of a Python process,
with all kinds of field caching, but also things like the way
relationship fields are resolved on startup. So even if you put
something together that appears to kind of work, expect there to be a
lot of corner cases and things that outright won't work.

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 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/20170105200033.GH1628%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: request.read() is empty in POST

[Michal Petrucha]

On Fri, Dec 30, 2016 at 01:50:51PM -0800, Flávio Cardoso wrote:
> Hello! I'm getting crazy, PLEASE someone, give me some light!!!
> 
> I'm using Django 1.10.4, Python 3.5 on Windows using Visual Studio 
> Community 2015.
> 
> I have some class-based views to response some json.
> 
> from django.views.generic import View
> from json import loads
> from bson.json_util import dumps
> from django.http import HttpResponse, HttpRequest
> 
> class Topicos(View):
>def post(self, request):
>req = request.read().decode(self.request.encoding)
> 
> Have the following setting on urls.py:
> 
> url(r'^api/Topicos', Topicos.Topicos.as_view(), name='Topicos'),
> 
> The request.read() is empty, the request is: 
> 
> POST /api/Topicos HTTP/1.1
> Host: localhost:55020
> Connection: keep-alive
> Content-Length: 93
> Accept: application/json, text/plain, */*
> Origin: http://localhost:55020
> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 
> (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
> X-CSRFToken: 
> VRiCt3Lz1EIdKGWt3lknpcgdFpD8XbrwSxdPT4P9dd1tbrGYmgE8uHdEIH2dzP5h
> Content-Type: application/json;charset=UTF-8
> Referer: http://localhost:55020/
> Accept-Encoding: gzip, deflate, br
> Accept-Language: pt-BR,pt;q=0.8,en-US;q=0.6,en;q=0.4
> Cookie: 
> csrftoken=VRiCt3Lz1EIdKGWt3lknpcgdFpD8XbrwSxdPT4P9dd1tbrGYmgE8uHdEIH2dzP5h
> 
> {"titulo":"Título 1","mensagem":"mensagem","email":"fla...@email.test
> .br","usuario":"Flávio"}
> 
> 
> I really don't know what else I can do. I have the same code (except na 
> class name) running correctly to another posts.

Hi Flávio,

The behavior of request.read() is somewhat icky, and there are some
caveats when trying to use it. Let me give you a lengthy answer
starting from the basics down to the nasty corner cases that you're
likely encountering.

Basically, there are several interfaces that make it possible to
access the request body:

1. request.POST, and request.FILES – these two are the most high-level
   easy-to-use dict-like objects that automatically attempt to parse
   the request body, but they only support multipart/form-data and
   application/x-www-form-urlencoded requests, otherwise they will be
   empty.

2. request.body loads the entire request body into memory on first
   access, and stores it as a bytestring in an attribute. This is good
   for relatively short requests that fit into memory, if they aren't
   URL-encoded or multipart (most commonly JSON or XML).

3. Finally, there's request.read(), request.readline(), iteration, and
   some other file-like methods intended for requests that are too
   large to fit into memory, which means you need to process them in a
   streaming fashion. This means that once you start using this
   interface, it is no longer possible to access the part of the
   request body that has already been consumed.

Now, an obvious, but not very helpful answer to your question would be
that the request body has already been consumed through request.read
or another file-like access before your call, which means any
subsequent calls to read() or attempts to iterate will return an empty
result.

How could this happen? There are many possibilities, but the most
likely ones are that it's a middleware triggering a read, that your
view is decorated by a decorator that triggers a read, or that one of
the superclasses is responsible. I'd recommend that you consider these
three possibilities first, and look through all applicable
middlewares, decorators and superclasses.

Now, what do you have to look for? Any iteration of the request, calls
to read, readline, readlines, or xreadlines. However, that's not all,
because even just accessing request.POST or request.FILES might under
certain circumstances also have the same effect, although that should
only apply to multipart requests.

It's hard to give you any more specific advice, because the issue is
not in the piece of code that you have posted (which is also probably
the reason why you didn't get any responses to the original question).

However, when dealing with JSON requests, it's usually a better idea
to just use request.body, rather than request.read(), specifically to
avoid this kind of problems. If trying to read request.body is raising
a RawPostDataException on you, complaining that you cannot access body
after reading from request's data stream, that means you need to look
at any code that's executed before that line and track down what is
performing that read earlier.

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

Re: Multiple Fields as Primary Key in MySQL - Django 1.10

[Michal Petrucha]

On Tue, Jan 03, 2017 at 01:56:00PM +0100, Simone Federici wrote:
> Hi,
> 
> from compositekey import db
> 
> On my compositekey project the development is stopped on 1.5 django release.
> https://github.com/simone/django-compositekey
> 
> The Django 1.6 release, with an huge ORM refactoring and a huge testing
> refactoring, let my work hard to maintains. What I understand after the 1.6
> release is that this fe external library.
> 
> As I know Michal Petrucha make a good job on GSoc 2011.
> However, I don't know when is in planning the composite key feature in the
> django release.
> 
> 
> best
> Simone

Hi Simone and Ramesh,

Unfortunately, at the moment, composite primary keys are still not
supported by Django. I have done a lot of work some years ago, but
ultimately, real life got in the way and I didn't find enough time and
energy to focus on this for a sufficiently long period of time to get
a patch of this magnitude over the finish line.

There have been a few other attempts over the years; the latest thread
from django-developers@ is fairly recent [1], but judging from the
lack of responses, there seems to be little progress on that front.

For the time being, it appears that your best bet is to alter your
database schema to include a surrogate key in each table – really,
it's the path of least resistance.

Cheers,

Michal

[1]: https://groups.google.com/d/msg/django-developers/wakEPFMPiyQ/DcXNfL4sCQAJ

-- 
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/20170103211742.GE1628%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: validate_email returns None for any or format

[Michal Petrucha]

On Tue, Dec 20, 2016 at 05:28:48AM -0800, NoviceSortOf wrote:
> 
> Why does validate_email return None irregardless of what is typed in?
> 
> >>> from django.core.validators import validate_email
> >>> x = validators.validate_email('t...@example.com')
> >>> print x
> None
> >>>
> 
> Shouldn't it be returning True or False?

According to
https://docs.djangoproject.com/en/1.10/ref/forms/validation/#validators:

> A validator is merely a callable object or function that takes a
> value and simply returns nothing if the value is valid or raises a
> ValidationError if not.

Cheers,

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 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/20161220134113.GB1628%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Phone number field in form/ model

[Michal Petrucha]

On Wed, Dec 14, 2016 at 09:36:06PM +0200, Sithembewena Lloyd Dube wrote:
> Hi,
> 
> Has anyone captured phone number information using a Form/ModelForm
> instance? I have the field as an IntegerField in my model and (for obvious
> reasons) it truncates the leading '0'. How have you solved this problem,
> anyone?

Easy – don't use integer input fields for phone numbers, use input
fields for short text strings with appropriate validation.

For example, you might want to look at some of the phone number fields
implemented in https://django-localflavor.readthedocs.io/en/latest/,
and take some inspiration from them.

Cheers,

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 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/20161214194702.GK22986%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Installing django on python3.5.2. Debian

[Michal Petrucha]

On Tue, Dec 13, 2016 at 01:16:52PM -0800, mihail.poplav...@gmail.com wrote:
> Hello! I have a problem with installing Django on python 3.5.2, Debian
> I can't install pip on this version of python. However, python 3.4 has pip.
> How can I install pip in python 3.5.2? 

If you installed Python from apt repositories, then you should almost
never use pip directly, in fact, there's very little reason for you to
have a system-level pip at all.

What you should do is create a virtualenv (either with the
python3-virtualenv package with the command “virtualenv”, or
python3-venv, using “python3 -m venv”). The virtualenv will already
contain a version of pip that you can use, and you're free to mess
with packages inside that virtualenv in whatever way you want.

The reason for this is that if you use pip with your system Python
installed from repositories, there's a high chance that you will
overwrite some of the essential repository-installed packages with
pip, which can render your entire Python installation unusable. This
does happen to people quite often, and it's quite difficult to recover
from.

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 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/20161214075129.GI22986%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Extending FieldField (the way ImageField does)

[Michal Petrucha]

On Sat, Nov 19, 2016 at 01:34:31PM -0800, Serge Wroclawski wrote:
> Hi all,
> 
> I've been a casual user of Django for years, but recently have need to make 
> a new field based on FileField. I decided to take a look at ImageField, 
> since it is very similar to what I'm doing.
> 
> Specifically I'm looking at using mutagen (python-mutagen) to get 
> information about audio files. Mutagen can tell me the bitrate, duration 
> and then tags for the audio.
> 
> That's quite similar to how ImageField uses PIL underneith, so all's good 
> there.
> 
> But in my investigation, I'm coming across some code I am having difficulty 
> following.
> 
> Both the ImageField itself and the ImageFieldDescriptor class call a method 
> on ImageField called update_dimension_fields.
> 
> The docstring says that it updates the field's width and height attributes, 
> but even after reading the code many times, I am not seeing where the 
> height and width are retrieved from the image itself, rather than either 
> being passed in values or values already in the database.

All right, so ImageFileDescriptor.__set__ calls
self.field.update_dimension_fields(instance, force=True), where
instance is a model instance, and self.field is an ImageField attached
to that model. ImageField.update_dimension_fields, in turn, calls
getattr(instance, self.attname), which runs the descriptor's __get__ –
that one ensures that the result is an instance of ImageFieldFile,

So at this point inside update_dimension_fields, the file variable is
an ImageFieldFile.

Next up, you can see that it does some checking to find out which
dimension fields to update, if any, and finally gets to the important
part:

# file should be an instance of ImageFieldFile or should be None.
if file:
width = file.width
height = file.height

So here, the dimensions are retrieved from an ImageFieldFile through
its width and height attributes. Where do those come from? If you look
at the ancestors of ImageFieldFile, you'll see that it inherits from
django.core.files.images.ImageFile. This class implements the width
and height properties, which call
django.core.files.images.get_image_dimensions. This is the meat of the
dimension-extracting code, which calls Pillow to do the heavy lifting.

I hope this makes it at least a little bit clearer.

> Another question here is in regards to tags. Similar to image's exif data, 
> these audio files can contain tags, and in the case of many formats (such 
> as Ogg Vorbis) this tag data can be relatively arbitrary. It would seem 
> then that I'm stuck with three ugly options:
> 
> 1. I can make an explicit reference in my new OggVorbisFileField for each 
> field that the user may care about in their model (ie title, artist) 
> similar to how it works with ImageField's height and width
> 
> 2. Instead of referencing each field, have an ugly "tags" field that 
> contains something like a pickle'd dictionary of key/value pairs
> 
> 3. Make an arbitrary set of key/value pairs in the DB through a many/many 
> relationship for each of the tags
> 
> The fields that I care about (title, artist, etc.) will already be stored 
> in my model that will contain the new OggVorbisField, so I'm wondering if 
> there's a best practice here that I should try to follow.

If the set of fields that you care about is a small one, and you
already have regular model fields for them, then personally, I'd
choose the first option. If you have any good reason to store all
metadata, then both options 2 and 3 make sense, although when it comes
to option 2, you shouldn't pickle dicts. Instead, if you're using
postgres, just use a HStoreField, or a JSONField; on other databases,
you can use one of the many JSON field implementations backed by a
simple TextField. Option 2 will be easier to implement and maintain
than option 3, I think, whereas option 3 is more “pure” in terms of
relational database design.

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 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/20161120092522.GV8307%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: django_admin database creation, after sql command depreciated

[Michal Petrucha]

On Fri, Nov 18, 2016 at 12:07:40AM -0800, Yalın Aksoy wrote:
> 
> 
> Hello,
> 
> 
> I was using django 1.3 and python 2.4 for a big scale project. I
> decided to update it to django 1.9 and python 2.7.
> 
> 
> Since django_admin's sql parameter is depreciated in 1.9, the update
> database creation method changed a lot.
> 
> I am using the command:
> 
> 
> "python /usr/local/django//manage.py makemigrations"
> 
>  
> 
> > "python /usr/local/django//manage.py migrate --fake-initial --
> > noinput --run-syncdb "
> 
> 
> for table creation. But my tables are not created and manage is
> printing this error in both commands.
> 
>  Traceback (most recent call last):
> >   File "/src/project/project-export/django/projectadmin/manage.py", line 
> > 13, in 
> > execute_from_command_line(sys.argv)
> >   File 
> > "/opt/python/lib/python2.7/site-packages/django/core/management/__init__.py",
> >  line 353, in execute_from_command_line
> > utility
> > utility.execute()
> >   File 
> > "/opt/python/lib/python2.7/site-packages/django/core/management/__init__.py",
> >  line 345, in execute
> > 
> > self.fetch_command(subcommand).run_from_argv(self.argv)
> >   File 
> > "/opt/python/lib/python2.7/site-packages/django/core/management/base.py", 
> > line 348, in run_from_argv
> > 
> > self.execute(*args, **cmd_options)
> >   File 
> > "/opt/python/lib/python2.7/site-packages/django/core/management/base.py", 
> > line 398, in execute
> > 
> > self.check()
> >   File 
> > "/opt/python/lib/python2.7/site-packages/django/core/management/base.py", 
> > line 426, in check
> > include_deployment_checks
> > include_deployment_checks=include_deployment_checks,
> >   File 
> > "/opt/python/lib/python2.7/site-packages/django/core/checks/registry.py", 
> > line 75, in run_checks
> > new_errors 
> > new_errors = check(app_configs=app_configs)
> >   File 
> > "/opt/python/lib/python2.7/site-packages/django/core/checks/urls.py", line 
> > 13, in check_url_config
> > 
> > return check_resolver(resolver)
> >   File 
> > "/opt/python/lib/python2.7/site-packages/django/core/checks/urls.py", line 
> > 23, in check_resolver
> > 
> > for pattern in resolver.url_patterns:
> >   File 
> > "/opt/python/lib/python2.7/site-packages/django/utils/functional.py", line 
> > 33, in __get__
> > res 
> > res = instance.__dict__[self.name] = self.func(instance)
> >   File 
> > "/opt/python/lib/python2.7/site-packages/django/core/urlresolvers.py", line 
> > 417, in url_patterns
> > patterns 
> > patterns = getattr(self.urlconf_module, "urlpatterns", 
> > self.urlconf_module)
> >   File 
> > "/opt/python/lib/python2.7/site-packages/django/utils/functional.py", line 
> > 33, in __get__
> > res 
> > res = instance.__dict__[self.name] = self.func(instance)
> >   File 
> > "/opt/python/lib/python2.7/site-packages/django/core/urlresolvers.py", line 
> > 410, in urlconf_module
> > 
> > return import_module(self.urlconf_name)
> >   File "/opt/python/lib/python2.7/importlib/__init__.py", line 37, in 
> > import_module
> > __import__
> > __import__(name)
> >   File "/usr/local/django/projectadmin/projectadmin/urls.py", line 4, in 
> > 
> > import projectadmin.views
> >   
> >   File "/usr/local/django/projectadmin/projectadmin/views.py", line 20, in 
> > 
> > from projectadmin.forms import UserCreationForm
> >   File "/usr/local/django/projectadmin/projectadmin/forms.py", line 252, in 
> > 
> > class UserCreationForm(forms.ModelForm):
> >   File "/usr/local/django/projectadmin/projectadmin/forms.py", line 256, in 
> > UserCreationForm
> > template_choice = form_utils.create_template_choices_field()
> >   File "/usr/local/django/projectadmin/projectadmin/form_utils.py", line 
> > 15, in create_template_choices_field
> > choices 
> > choices = [(x.id, x.template_name) for x in all_templates]
> >   File "/opt/python/lib/python2.7/site-packages/django/db/models/query.py", 
> > line 258, in __iter__
> > 
> > self._fetch_all()
> >   File "/opt/python/lib/python2.7/site-packages/django/db/models/query.py", 
> > line 1074, in _fetch_all
> > 
> > self._result_cache = list(self.iterator())
> >   File "/opt/python/lib/python2.7/site-packages/django/db/models/query.py", 
> > line 52, in __iter__
> > results 
> > results = compiler.execute_sql()
> >   File 
> > "/opt/python/lib/python2.7/site-packages/django/db/models/sql/compiler.py", 
> > line 848, in execute_sql
> > cursor
> > cursor.execute(sql, params)
> >   File 
> > "/opt/python/lib/python2.7/site-packages/django/db/backends/utils.py", line 
> > 64, in execute
> > 
> > return self.cursor.execute(sql, params)
> >   File "/opt/python/lib/python2.7/site-packages/django/db/utils.py", line 
> > 95, in __exit__
> > six
> > six.reraise(dj_exc_type, dj_exc_value, traceback)
> >   File 
> > 

Re: Setting up jQuery in debian with virtualenv

[Michal Petrucha]

On Wed, Nov 09, 2016 at 01:54:57PM -0800, Gary Roach wrote:
> Ludovic
> 
> Thank you for the reply but I know how to use static files. The problem is
> that I already have a jquery file under version control inside my virtual
> environment wrapper and do not wish to use an external file . Use of a
> normal static file will open my application up to uncontrolled version
> shifts. I want to know how to use the pip installed version of the jquery
> file if possible.
> 
> Gary R.

Could you please elaborate on that a little bit? Virtualenvs are
normally used to install Python packages, which jquery is not. Jquery
really *is* a static asset, it's just a file that the browser
downloads from your server as it is, without any server-side
processing. That's the definition of a static asset.

How do you install jquery? Are you using some kind of python-package
wrapper that contains the jquery static file? What package exactly is
it?

Chances are that if you use some kind of django-jquery package, all
you need to do is add that package to your ``INSTALLED_APPS``, and as
long as your ``STATICFILES_FINDERS`` setting includes
``django.contrib.staticfiles.finders.AppDirectoriesFinder``, it might
“just work” (as in, you'd reference it using
``{% static "js/jquery.js" %}`` or something).

However, that's just a guess, because it's not very clear to me from
your description what kind of setup you have there. Anyway, as far as
Django is concerned, it really does not care where the static file is
coming from, as long as you configure your static file finders to see
the file.

Cheers,

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 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/20161110083709.GP8307%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: External access

[Michal Petrucha]

On Mon, Nov 07, 2016 at 08:48:25AM -0500, bob gailer wrote:
> I am running a the django server, listening at port 8000. I can access the
> server using localhost. When I try using my external ip address I get "The
> server at 24.211.133.163 is taking too long to respond." I have port 8000
> forwarded to my server computer in my router. What more do I need to do?

By default, runserver only binds to 127.0.0.1:8000, which makes it
only accessible over the loopback interface. If you want to make it
accessible from all interfaces, try starting it up like this:

./manage.py runserver 0.0.0.0:8000

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 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/20161107142550.GM8307%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Django1.9 Mongodb support

[Michal Petrucha]

On Fri, Nov 04, 2016 at 12:33:51PM -0700, Sudhir kumar Giri wrote:
> Hello,
>  I didn't find any documentation or tutorial for Django-1.9 with Mongodb.
> Please suggest some docs about it.
> Thanks

Hi,

Django does not have any specific support for mongodb. Of course, you
can just use Django without its ORM, and simply use some other Python
library to access mongo.

There used to be a few projects trying to bring support for
nonrelational database (with most focus on mongo) to Django's ORM, but
the entire point of an ORM is sort of to serve as a layer on top of
relational data stores, and the last time I checked, neither of those
projects was maintained anymore.

May I ask if you have any specific reason to want to use mongo with
Django? If not, you're most likely better off using Postgres instead,
which has excellent support in Django.

Cheers,

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 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/20161104212437.GL8307%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Redirect after Form

[Michal Petrucha]

On Sun, Oct 30, 2016 at 06:39:19AM -0700, Moreplavec wrote:
> I found in Django Tutorial solution: 
> https://docs.djangoproject.com/en/1.10/intro/tutorial04/ :
> 
> Now i have: 
> 
> return HttpResponseRedirect(reverse('crm:company_detail', args=(company.pk,)))
> #return redirect('views.company_detail', pk=company.pk)
> 
> 
> And it works fine!

Just for the record, you should also be able to use this::

return redirect('crm:company_detail', company.pk)

(That should be equivalent to the explicit HttpResponseRedirect with
reverse().)

Cheers,

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 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/20161031092105.GJ8307%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Visiting one Django server logs me out of another Django server, both behind the same proxy

[Michal Petrucha]

Hi Mike,

On Fri, Sep 30, 2016 at 06:00:30AM -0700, Stodge wrote:
> Thanks Michal,
> 
> The two servers are on the same domain and use different databases. At the 
> moment I'm using the default Django session backend.
> 
> It's an experiment, nothing more really. I just wanted to see if I could 
> make it work. I haven't really worked out the flow, but it's probably 
> something like:
> 
>  - admin creates user account on A1, auto replicates it to S1
>  - user U1 visits S1, not logged in
>  - U1 redirected to A1 to generate auth token, not logged in
>  - U1 logs into A1
>  - U1 redirected back to S1 to accept authentication
>  - S1 logs U1 in, creates session as normal
> 
> So the user is logged into both. It's a fairly naive attempt at reinventing 
> the wheel, but that's how we learn, right? :)

Sounds all right, at least from a higher-level point of view. So
basically, those two services are pretty much separate, just sharing a
domain. In this case, your problem should go away if you set a unique
SESSION_COOKIE_NAME for each of those sites.

It might be a different situation if those two sites were using a
shared database; then, the same session ID would be valid for both,
but since that's not the case here, they need to be separate.

Cheers,

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 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/20160930132620.GZ6601%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Visiting one Django server logs me out of another Django server, both behind the same proxy

[Michal Petrucha]

On Thu, Sep 29, 2016 at 01:50:22PM -0700, Stodge wrote:
> I have two Django servers A1 and S1, which sit behind a simplistic
> NodeJS proxy. This is a silly attempt at single sign on.
> 
> I can log into and out of A1 (authentication server) just fine. If I
> log into A1, visit S1 (without being logged in to S1) and then
> revisit A1, I am no longer logged in. The S1 server doesn't set a
> new session ID in the cookie and I don't think from memory that the
> CSRF changes. The session ID cookie hasn't changed, the domain is
> the same etc.
> 
> I can't work out why I'm no longer logged into A1. I know this isn't
> much to go on but I'm assuming something is happening to the cookies
> set by S1 when I visit it. Any suggestions appreciated.

Are those two applications sitting on the same domain? If yes, then
you should probably configure them to use different session cookies.
Logging in or out causes the session to be reset, and if they try to
use the same session cookie, resetting for either application will
reset it for both.

It's hard to give you any more specific advice, because there are many
ways to go about implementing SSO, some of which would be affected by
this.

You might want to share some more information, such as:

- Are those two applications sharing one database?
- What session backend are you using?
- Are they on the same domain? (this one I've already asked above)
- Could you describe the SSO flow in a bit more detail?

Cheers,

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 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/20160930082844.GX6601%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Cache-Control header for Flat Pages

[Michal Petrucha]

On Thu, Sep 29, 2016 at 05:17:54AM -0700, Web Architect wrote:
> Hi Michal,
> 
> Thanks for your response. My mistake that I should have mentioned that we 
> are using Django 1.8. The decorator cache_control I think was introduced in 
> 1.9. Would there be something similar in 1.8?

It's also in 1.8:
https://docs.djangoproject.com/en/1.8/topics/cache/#controlling-cache-using-other-headers

(And yeah, I just verified that I can import it in a 1.8 project.)

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 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/20160929131430.GU6601%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Cache-Control header for Flat Pages

[Michal Petrucha]

On Thu, Sep 29, 2016 at 03:47:11AM -0700, Web Architect wrote:
> Hi Serge,
> 
> Thanks for your response.
> 
> We do not have any Views implemented for flatpages. I think they are Django 
> internal stuff for static html content (something like a CMS):
> 
> https://docs.djangoproject.com/en/1.10/ref/contrib/flatpages/
> 
> Have used the url pattern as in the example mentioned in the link above:
> 
> from django.contrib.flatpages import views
> urlpatterns += [
> url(r'^about-us/$', views.flatpage, {'url': '/about-us/'}, name='about'),
> url(r'^license/$', views.flatpage, {'url': '/license/'}, name='license'),]

You can use the cache_control view decorator to wrap the flatpage view
before you plug it into your urlpatterns::

from django.contrib.flatpages import views
from django.views.decorators.cache import cache_control

cached_flatpage = cache_control(max_age=4700)(views.flatpage)

urlpatterns += [
url(r'^about-us/$', cached_flatpage, {'url': '/about-us/'}, 
name='about'),
url(r'^license/$', cached_flatpage, {'url': '/license/'}, 
name='license'),]

Cheers,

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 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/20160929113704.GT6601%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: cannot import name SortedDict

[Michal Petrucha]

On Tue, Sep 20, 2016 at 11:21:20AM -0400, Etienne Robillard wrote:
> Hi Alessandro,
> 
> I have replaced the only occurrence of SortedDict with
> collections.OrderedDict in app_plugins, but the issue persist.
> 
> Is it possible that the templatetags module is being cached somehow by
> Django ?
> 
> Thanks,
> 
> Etienne

No, Django caching never applies to Python code. However, as with any
code change, you need to make sure to restart the Python process
(i.e., if you're running under gunicorn or uwsgi, restart those, if
you're using runserver, you might have to try restarting it – most of
the time, runserver tries to reload itself automatically, but there
are pathological cases where it doesn't work).

If that doesn't help, try checking if there are any stale leftover
.pyc files, and try removing those.

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 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/20160920152542.GI6601%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Random 404 instead of 301 for URLs without trailing slash

[Michal Petrucha]

Hi Frederik,

On Fri, Sep 16, 2016 at 09:01:53AM -0700, Frederik Elwert wrote:
> Hello,
> 
> I am running a site that uses Django 1.8 and Django CMS 3.2. The site is 
> deployed using gunicorn and nginx. Now I noticed a strange, hard to debug 
> issue: When accessing a URL without trailing slash, I expect a redirect to 
> the correct URL with the trailing slash appended, as per the APPEND_SLASH 
> setting. This usually works, but sometimes I get a 404 instead of the 
> correct 301. I can reproduce this using curl:
> 
> $ curl -I http://khk.ceres.rub.de/en/research/focus-groups/notions
> HTTP/1.1 404 NOT FOUND
> Server: nginx/1.6.2
> Date: Fri, 16 Sep 2016 15:54:40 GMT
> Content-Type: text/html
> Connection: keep-alive
> x-xss-protection: 1; mode=block
> Content-Language: en
> x-content-type-options: nosniff
> Vary: Cookie
> X-Frame-Options: SAMEORIGIN
> Set-Cookie: django_language=en; expires=Sat, 16-Sep-2017 15:54:40 GMT; 
> Max-Age=31536000; Path=/
> 
> $ curl -I http://khk.ceres.rub.de/en/research/focus-groups/notions
> HTTP/1.1 301 MOVED PERMANENTLY
> Server: nginx/1.6.2
> Date: Fri, 16 Sep 2016 15:54:42 GMT
> Content-Type: text/html; charset=utf-8
> Connection: keep-alive
> x-xss-protection: 1; mode=block
> Content-Language: en
> x-content-type-options: nosniff
> Vary: Cookie
> Location: http://khk.ceres.rub.de/en/research/focus-groups/notions/
> X-Frame-Options: SAMEORIGIN
> Set-Cookie: django_language=en; expires=Sat, 16-Sep-2017 15:54:42 GMT; 
> Max-Age=31536000; Path=/
> 
> I am a bit clueless why this behaviour is so unpredictable. Any ideas what 
> might be going on here, or how to trace this?

APPEND_SLASH only applies to URLs that do not match any URL pattern.
It is possible that you have a catch-all urlpattern that happens to
match your URL without a trailing slash, and then raise an explicit
404 – this might happen, for instance, if you're using something like
a wiki application, or a custom handler for flatpages, included under
a particular URL prefix.

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 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/20160916163757.GY6601%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Django exit function

[Michal Petrucha]

On Sat, Sep 10, 2016 at 01:51:00AM -0700, Krešimir wrote:
> Hello,
> 
> I have a turn_the_light_on() function that, well, turns on a light...
> I put it in wsgi.py (as suggested by internet) just before application = 
> get_wsgi_application()call.
> 
> Where can I put turn_the_light_off() function call to turn off the light 
> when the application quits?
> 
> Thank you!

In short, there is no such thing. In the most common scenario
(including yours, based on your email), Django is used as a WSGI
application, which starts up once, and then lives inside an
application server, which listens to requests, and translates them
into function calls. In that sense, Django is more of a passive thing,
that waits to be called with a request, which it then dutifully
processes, and finally enters the waiting state again. This happens
until the application server itself exits, but that is out of the
scope of what Django does.

Usually, application servers also just run indefinitely, until they
are killed. Or you can configure them to only run for a certain amount
of time. Or you can set them up to quit and restart after they process
a certain number of requests. Either way, the shutdown sequence
usually consists of just terminating the process.

What you are asking for sounds like it falls into the responsibility
of your application server. For example, Gunicorn has an ``on_exit``
hook [1], or if you're using uwsgi, it also has some hooks [2], though
I haven't been able to extract much useful information at a glance,
but you might be able to find something that suits your need.

Cheers,

Michal


[1]: http://docs.gunicorn.org/en/latest/settings.html#on-exit
[2]: https://uwsgi-docs.readthedocs.io/en/latest/Hooks.html

-- 
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/20160910152635.GP6601%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: How modify Django to set URLs with decorators on the view functions like Flask? (rather than using urls.py)

[Michal Petrucha]

On Fri, Sep 09, 2016 at 10:11:25PM -0700, Chris Seberino wrote:
> Flask has a neat design where instead of having a urls.py file they bind 
> URLs to view functions with decorators.
> 
> Possible to do something similar with Django?  What modifications would be 
> needed?

Personally, I'm not a big fan of the standard Flask pattern where URL
routing is set up as a side effect of importing view modules, rather
than having an explicit place that reliably defines the exact list of
patterns that will be used in a clearly-defined order no matter what.
The Flask pattern leaves a lot of room for inconsistent behavior
across processes, depending on the order in which the modules
containing views were imported.

That being said, you can easily put something like this into your
``mysite/urls.py``::

from django.conf.urls import url

urlpatterns = []

def route(pattern, **kwargs):
def inner(view_function):
urlpatterns.append(url(pattern, view_function, **kwargs))
return view_function

Then, you'd just import the route decorator, and define your views
like this::

from mysite.urls import route


@route(r'^/neat-view/$', name='neat')
def my_view(request):
return HttpResponse("Neat!")


If you feel like it, you can go wild, and do some more hand stuff in
there, like inspect the function's name, and automatically register
the pattern with the same name, or possibly even more cool stuff.

Keep in mind that if you do something like this, you're going against
established patterns in the Django world, which will make your
application harder to understand for people who are already familiar
with the way one does routing with Django.

Django itself has been steadily moving away from doing import-time
side-effect magic, towards handling application initialization as
explicitly as possible, and for good reason. Explicit initialization
does not rely on coincidental circumstances, like the order of import
statements, and makes it possible to detect errors early on and fail
immediately, instead of running in a semi-broken state happily without
ever telling anyone.

Cheers,

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 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/20160910112946.GO6601%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Maintaining old django code

[Michal Petrucha]

On Tue, Sep 06, 2016 at 11:12:14AM +0200, Andreas Kuhne wrote:
> 2016-09-06 10:57 GMT+02:00 Erik Cederstrand :
> 
> >
> > > Den 6. sep. 2016 kl. 10.20 skrev Lekan Wahab :
> > >
> > > Good morning guys.
> > > I was handed a project at work which was written as far back as 2012.
> > > Quiet a lot of the packages used in the project are either no longer
> > being maintained.
> > > Rebuilding the project from scratch is not option.
> > > There are way too many moving parts and way too many apps to rebuild it.
> > > Here are my questions:
> > >
> > > 1. In the scenario i am in, what would be the best approach to update
> > this project or at least get it set up locally?
> >
> > First, get the project to run on your local machine with the exact same
> > package versions as was specified originally. You may have to look in
> > lib/pythonx.x/site-packages on wherever it was running before, for the
> > exact versions used, if there is no requirements file. Run the test-suite
> > for your project and make sure everything is working.
> >
> > Second, write more tests! You need lots of tests to verify any future
> > changes you make to your own and external packages.
> >
> > Third, either upgrade external packages to the newest versions, find
> > alternatives if they are no longer maintained, or maintain the external
> > package yourself from now on (assuming the license permits, of course). If
> > the packages depend Django, you may have to do this gradually, as the
> > newest package versions may no longer support Django 1.4 (see below).
> >
> > > 2.  Quite a lot of changes have been made between django 1.4 (which was
> > originally used) and the current version(1.10), what would be the best
> > version for me to update the project to.
> > > I mostly use 1.8 anyway.
> >
> > Take one minor Django version at a time, reading the upgrade notes along
> > the way. Update your code to the new way of doing things, and move on to
> > the next version. That's the supported and recommended way. Even though
> > that's six versions to upgrade to, it will probably save you time in the
> > long run instead of upgrading from 1.4 -> 1.10 in one go.
> >
> > Happy coding!
> >
> >
> This is probably a requirement - to do each minor upgrade. I don't think it
> is possible to migrate from 1.4 to 1.10 directly. There are too many
> deprecations for that. That being said, shouldn't it be possible to migrate
> from one LTS to another? And if memory serves correctly, 1.4 should be an
> LTS?

I think that this policy will only apply from 2.0 on [1] – back when
1.4 was supported, this new backwards compatibility policy was still
just in the works, and the usual “two releases” policy applied. So no,
at the very least, when going from 1.4 to 1.8, you should make an
intermediate stop at 1.6, but if you want to minimize the pain, going
through every single feature release would probably be the best idea.

[1]: https://docs.djangoproject.com/en/1.10/internals/release-process/

Cheers,

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 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/20160906094026.GK6601%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: django.core.exceptions.FieldDoesNotExist but the field exists

[Michal Petrucha]

On Mon, Sep 05, 2016 at 08:44:55AM -0700, Stefano Tranquillini wrote:
> Hello
> 
> I've a problem syncing the db.
> 
> I run the command: django-admin migrate
> 
> System check identified some issues:
> Operations to perform:
>   Synchronize unmigrated apps: oauth2_provider, 
>   Apply all migrations: admin, Synchronizing apps without 
> migrations:
>   Creating tables...
> Running deferred SQL...
>   Installing custom SQL...Running migrations:
>   No migrations to apply.Traceback (most recent call last):
>   File "/Users/stefano/.virtualenvs/prjrest/bin/django-admin", line 11, in 
> 
> sys.exit(execute_from_command_line())
>   File 
> "/Users/stefano/.virtualenvs/prjrest/lib/python2.7/site-packages/django/core/management/__init__.py",
>  line 354, in execute_from_command_line
> utility.execute()
>   File 
> "/Users/stefano/.virtualenvs/prjrest/lib/python2.7/site-packages/django/core/management/__init__.py",
>  line 346, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File 
> "/Users/stefano/.virtualenvs/prjrest/lib/python2.7/site-packages/django/core/management/base.py",
>  line 394, in run_from_argv
> self.execute(*args, **cmd_options)
>   File 
> "/Users/stefano/.virtualenvs/prjrest/lib/python2.7/site-packages/django/core/management/base.py",
>  line 445, in execute
> output = self.handle(*args, **options)
>   File 
> "/Users/stefano/.virtualenvs/prjrest/lib/python2.7/site-packages/django/core/management/commands/migrate.py",
>  line 208, in handle
> changes = autodetector.changes(graph=executor.loader.graph)
>   File 
> "/Users/stefano/.virtualenvs/prjrest/lib/python2.7/site-packages/django/db/migrations/autodetector.py",
>  line 43, in changes
> changes = self._detect_changes(convert_apps, graph)
>   File 
> "/Users/stefano/.virtualenvs/prjrest/lib/python2.7/site-packages/django/db/migrations/autodetector.py",
>  line 165, in _detect_changes
> old_field = self.old_apps.get_model(app_label, 
> old_model_name)._meta.get_field(field_name)
>   File 
> "/Users/stefano/.virtualenvs/prjrest/lib/python2.7/site-packages/django/db/models/options.py",
>  line 554, in get_field
> raise FieldDoesNotExist('%s has no field named %r' % (self.object_name, 
> field_name))
> django.core.exceptions.FieldDoesNotExist: CustomerKey has no field named 
> u'customer_key_cipher_text'
> 
> So, it seems that there are not migration, but still django complains for a 
> missing field. 
> 
> However in the model the field is there
> 
> 
> class CustomerKey(models.Model):...
> customer_key_cipher_text = Base64Field(default='')
> 
> Any idea on what's the problem?

According to the stack trace, this error happens when the autodetector
is trying to get the model field from a previous state of the models,
which is determined from the migration history, not the current model
definitions.

Have you by any chance made any changes to any of the existing
migrations? I can imagine that this could happen if one of your
migrations tries to make an AlterField operation on a field that
hasn't been created in any of the preceding 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 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/20160905155543.GJ6601%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: A tricky query in one to many relationship - atleast for me:)

[Michal Petrucha]

On Tue, Aug 30, 2016 at 11:46:14PM -0700, Web Architect wrote:
> Hi Erik,
> 
> I tried your solution but there are some issues:
> 
> .filter(date_created=Max('a__b__date_created'))  - this is throwing error 
> saying not proper use of group function.
> 
> If I remove the above, the result isn't correct where when I go through 
> each 'a' in the result, associated latest B.text isn't always 'ABCD' - if 
> there are multiple instances of B associated with an instance of A and one 
> of the instances of B has text='ABCD' (might not be the latest 
> date_created), that instance of B is also there in the query result.

Hmm, I haven't actually tried to run any code, but I'd try reordering
some of the method calls, and using an explcit field alias for the
annotation, which should let you then use an F() expression in
subsequent filters; something like this:

A.objects.filter( 
b__in=B.objects 
.annotate(max_date_created=Max('a__b__date_created')) 
.filter(date_created=F('max_date_created'), text='ABCD') 
) 

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 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/20160831081747.GF6601%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Attribute error, with a very basic banking app

[Michal Petrucha]

On Fri, Aug 26, 2016 at 10:29:16AM -0400, Andromeda Yelton wrote:
> In my experience, CBVs are useful when the view you want to write is
> basically a create, read, update, or delete operation on a single database
> item, or a bunch of instances of the same model (...and it turns out a lot
> of web app pages are just that). And they're useful because they let you do
> that with almost no lines of code - they take care of all the things you'd
> have to write over and over, and let you focus on the things that are
> unique to your use case.
> 
> The farther away your business logic is from that, the more you need to
> understand the actual methods available and the inheritance tree and so
> forth. It took me a while to get over this hurdle too, but now that I have
> I use CBVs exclusively.

I'll just chime in with a reference to http://ccbv.co.uk/, which is an
invaluable resource whenever you're doing anything with CBVs that
involves more than setting the ``template_name`` and ``model``
attributes. In my opinion, CCBV makes a lot of the pain involved in
dealing with CBVs go away.

Cheers,

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 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/20160826144853.GA6601%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Starting new project -- version 1.10

[Michal Petrucha]

On Mon, Aug 22, 2016 at 07:48:44AM -0700, Rich Shepard wrote:
>   One clarification on projects vs applications will help my learning.
> Rather than using the same name for both (based on prior advice), the
> project name is clientmanagment and that directory contains
>   clientmanagement/  crm/  manage.py*
> 
>   The clientmanagement/ subdirectory contains
>   __init__.py   __pycache__/  settings.pyc  wsgi.py
>   __init__.pyc  settings.py   urls.py
> 
> and I wonder why the project-related files in this subdirectory are not
> under the parent project directory. In other words, why is there a project
> subdirectory under the project directory?

This is mostly an issue with how we name things. You have a project,
which is a CRM application. That's the entire thing, which consists of
a bunch of different Python packages. So, each of the subdirectories
in the top-level “clientmanagement” directory is one Python package.
For better or for worse, Python packages containing Django models,
views, URL patterns, and whatnot, are referred to as “Django apps”.

So you have a project named “clientmanagement”, which contains two
Python packages (in other words Django apps), called “crm”, and
“clientmanagement”.

Usually, it's a good practice to split your project into smaller
self-contained packages. Those all live together inside the project
directory, and each of them can have its own URL patterns, models,
views, static files, templates, and pretty much anything else. They
can even depend on each other, although it's often a good idea to keep
the coupling between as low as possible.

Finally, you need one Python package that serves as the “app” that
glues all the other packages together. This is the package (or app)
that contains the settings module, the root URL configuration, the
WSGI entry point, and often also static files, templates, views and
other stuff that only make sense in the context of the project itself,
and cannot reasonably be spun out into a separate package (that would
be things like the base template, or sometimes the landing page view).
This is what you referred to as the “project-under-the-project”.

The reason why this is inside a separate subdirectory is that you want
Python to be able to import it. In theory, you could just put
everything one level higher (and, in fact, that used to be the default
layout created by startproject until a few years ago), but it's
troublesome in practice, because with such layout, all of those files
end up in the global Python import namespace, which can easily lead to
conflicts.

As a final note, if your entire project is really small, and only does
one single thing, it's not entirely unreasonable to use a single
Python package (Django app) for everything – if there are no more than
a couple-three models in the entire project, and just a handful of
views and forms, I just stuff everything into the single package
created by startproject.

I hope this explanation makes sense, and feel free to ask if there's
anything unclear.

Cheers,

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 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/20160823121159.GO27882%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: receiving PNG file in django

[Michal Petrucha]

On Mon, Aug 22, 2016 at 11:10:38AM -0400, Larry Martell wrote:
> On Mon, Aug 22, 2016 at 11:00 AM, Michal Petrucha
> <michal.petru...@konk.org> wrote:
> > On Mon, Aug 22, 2016 at 10:11:49AM -0400, Larry Martell wrote:
> >> When I get the request, request.FILES is empty. Yet the content type
> >> is multipart/form-data and the method is POST:
> >>
> >> (Pdb) print request.META['CONTENT_TYPE']
> >> multipart/form-data;
> >> boundary="boundary_.oOo._NzEwNjIzMTM4MTI4NjUxOTM5OQ==MTY2NjE4MDk5Nw=="
> >>
> >> (Pdb) print request.META['REQUEST_METHOD']
> >> POST
> >>
> >> (Pdb) print request.FILES
> >> 
> >>
> >> The individual files are being sent with content-type
> >> 'application/octet-stream', and it looks like I get the contents of
> >> the files converted to unicode:
> >>
> >> (Pdb) 
> >> type(request.POST['right-carotidartery:63B2E474-D690-445F-B92A-31EBADDC9D93.png'])
> >> 
> >
> > Are you certain the request contains correct headers for files? In
> > particular, look at the “Content-Disposition” header; for each file,
> > it should contain the “filename” attribute; otherwise, Django will
> > treat it as a regular (non-file) form field [1]. As an example, the
> > header could look like this::
> >
> > Content-Disposition: form-data; name="file"; filename="filename.png"
> 
> How would I access the Content-Disposition for each file? In the
> headers for the request that field does not exist.

What I'm suggesting is that you look at the raw HTTP request that's
going over the wire, or investigate the client that's making the
request. I'm not sure if there's any reasonable way to work around
this on the Django side.

-- 
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/20160822151429.GN27882%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: receiving PNG file in django

[Michal Petrucha]

On Mon, Aug 22, 2016 at 10:11:49AM -0400, Larry Martell wrote:
> When I get the request, request.FILES is empty. Yet the content type
> is multipart/form-data and the method is POST:
> 
> (Pdb) print request.META['CONTENT_TYPE']
> multipart/form-data;
> boundary="boundary_.oOo._NzEwNjIzMTM4MTI4NjUxOTM5OQ==MTY2NjE4MDk5Nw=="
> 
> (Pdb) print request.META['REQUEST_METHOD']
> POST
> 
> (Pdb) print request.FILES
> 
> 
> The individual files are being sent with content-type
> 'application/octet-stream', and it looks like I get the contents of
> the files converted to unicode:
> 
> (Pdb) 
> type(request.POST['right-carotidartery:63B2E474-D690-445F-B92A-31EBADDC9D93.png'])
> 

Are you certain the request contains correct headers for files? In
particular, look at the “Content-Disposition” header; for each file,
it should contain the “filename” attribute; otherwise, Django will
treat it as a regular (non-file) form field [1]. As an example, the
header could look like this::

Content-Disposition: form-data; name="file"; filename="filename.png"

> I've tried to decoding it with:
> 
> unicodedata.normalize('NFKD', request.POST[key]).encode('ascii','ignore'))
> 
> But that did not create a valid PNG file. It seems that something
> mistakenly encoded to unicode. What would be doing that?

By this point, it's too late – Django has already treated the field as
a string field, so it's already called
``force_text(data, encoding, errors='replace')`` [2], which means the
value you have there has already lost some information that is
impossible to get back [3].

And even if it was reversible, performing a Unicode normalization, and
then throwing away everything non-ASCII would most certainly not be
the correct way, since it would mangle about one half of the input
data into ASCII.

> Any suggestions on how I can make this work?

You'll have to make sure that the request is correct, I'm afraid.

Good luck,

Michal


[1]: 
https://github.com/django/django/blob/a8f957797d8035a542cdb20b03aaebd81b9529e2/django/http/multipartparser.py#L638-L641
[2]: 
https://github.com/django/django/blob/a8f957797d8035a542cdb20b03aaebd81b9529e2/django/http/multipartparser.py#L207
[3]: https://docs.python.org/2/library/codecs.html#codec-base-classes

-- 
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/20160822150034.GM27882%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Starting new project -- version 1.10

[Michal Petrucha]

On Fri, Aug 19, 2016 at 02:05:18PM -0700, Rich Shepard wrote:
> On Fri, 19 Aug 2016, Tim Graham wrote:
> 
> >Don't use the same name for your app and project. When you "startproject
> >crm", the project settings.py, urls.py, and wsgi.py are placed in a module
> >named "crm" so you can't use the same name for an app.
> 
> Tim,
> 
>   I read that but overlooked the implications.

Hi Rich,

Just to add to what Tim wrote, there's no reason why you couldn't use
the crm package created by startproject as an “app”, too – all you
have to do is create a models.py file in there (next to the existing
urls.py, if you need any models), views.py (if you need views), and
add 'crm' to ``INSTALLED_APPS``. That's pretty much the same thing as
what startapp would have done, anyway.

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 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/20160822082445.GL27882%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Odd problem: some database updates do not appear on other pages until server restart

[Michal Petrucha]

On Fri, Aug 19, 2016 at 02:38:02PM +0200, Michal Petrucha wrote:
> On Fri, Aug 19, 2016 at 05:02:39AM -0700, bobhaugen wrote:
> > On Friday, August 19, 2016 at 5:20:45 AM UTC-5, Michal Petrucha wrote:
> > These questions remain unanswered, although I intend to do a bunch more 
> > testing:
> > 
> >1. How pervasive is this problem? Does it affect template variables like 
> >{{ object.foreign_key_method }} where the foreign_key_method returns a 
> >queryset?
> >2. Is this behavior clearly documented anywhere?
> 
> Honestly, I'm not sure what exactly you're asking here. Your
> implementation of ``with_user`` was hard-wiring a queryset filter
> based on the state of the database at the time ``with_user`` was
> called. The rest is just standard Python behavior – since the method
> was called during import (in the ModelForm definition), the result of
> that call was used for the rest of the process' lifetime.

Actually, let me rephrase that. This problem you encountered here
wasn't a case of “you need to set the ``queryset`` argument of
``ModelChoiceField`` in your form's ``__init__``,” but rather a case
of “don't do too much filtering in your Python code – let your
database do the filtering”.

Using ``__init__`` to set the queryset is not really a very standard
thing to do. It's just a workaround to make a form work if it uses a
manager or queryset method that does not behave entirely correctly.

Does this help make things at least a little bit clearer?

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 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/20160819131204.GK27882%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Odd problem: some database updates do not appear on other pages until server restart

[Michal Petrucha]

On Fri, Aug 19, 2016 at 05:02:39AM -0700, bobhaugen wrote:
> On Friday, August 19, 2016 at 5:20:45 AM UTC-5, Michal Petrucha wrote:
> >
> > Could you show us the code of with_user? Maybe it does not return an 
> > unevaluated queryset? 
> >
> >  
> def with_user(self):
> all_agents = EconomicAgent.objects.all()
> ua_ids = []
> for agent in all_agents:
> if agent.users.all():
> ua_ids.append(agent.id)
> return EconomicAgent.objects.filter(id__in=ua_ids)
> 
> Moving the call to with_user to form.__init__ solved the problem in the 
> form ModelChoiceField.

Thanks for sharing the code. The problem is that the ``with_user``
method, which was called during import, eagerly evaluates
``EconomicAgent.objects.all()`` right away, and returns a QuerySet
filtered by the result of that. So even though the final queryset
returned by ``with_user`` is not yet evaluated, the filtering
condition in that queryset is already fixed.

You could fix this by doing something along the lines of::

def with_user(self):
return EconomicAgent.objects.filter(users__isnull=False).distinct()

The important difference is that this version of ``with_user`` does
not evaluate anything eagerly, but rather sets up the necessary
filters to get the correct result set at the time of evaluation of
that queryset.

Depending on what you do with the queryset further, you might need to
change it a little bit to remove the ``distinct()`` call, and use a
subquery instead.

> These questions remain unanswered, although I intend to do a bunch more 
> testing:
> 
>1. How pervasive is this problem? Does it affect template variables like 
>{{ object.foreign_key_method }} where the foreign_key_method returns a 
>queryset?
>2. Is this behavior clearly documented anywhere?

Honestly, I'm not sure what exactly you're asking here. Your
implementation of ``with_user`` was hard-wiring a queryset filter
based on the state of the database at the time ``with_user`` was
called. The rest is just standard Python behavior – since the method
was called during import (in the ModelForm definition), the result of
that call was used for the rest of the process' lifetime.

Cheers,

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 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/20160819123802.GJ27882%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Odd problem: some database updates do not appear on other pages until server restart

[Michal Petrucha]

On Thu, Aug 18, 2016 at 11:57:40AM -0700, bobhaugen wrote:
> On Thursday, August 18, 2016 at 1:34:29 PM UTC-5, Tim Graham wrote:
> >
> > I'd guess you're doing a query for the form field's choices at the module 
> > level which will be executed once and cached for as long as the server 
> > runs. See if 
> > https://docs.djangoproject.com/en/stable/ref/forms/fields/#fields-which-handle-relationships
> >  
> > helps, otherwise please post the code for the form in question.
> >
> > Ohhh, Tim! You might just have nailed it! Yes I am.
> 
> Here's the relevant code for the form field:
>  
> ```
> from_agent = forms.ModelChoiceField(
> required=False,
> queryset=EconomicAgent.objects.with_user(),
> ```
> 
> with_user() is a method of
> class AgentManager(models.Manager)

Could you show us the code of with_user? Maybe it does not return an
unevaluated queryset?

Cheers,

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 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/20160819101915.GI27882%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: selectively requiring login

[Michal Petrucha]

On Mon, Aug 01, 2016 at 10:12:53PM +0200, ludovic coues wrote:
> The session cookie ?
> 
> Or you could use another decorator or a middle-ware doing
> authentication based on the ip and some information passed as get
> argument. Like a token returned by django when you auth the user.

Using the IP address to authenticate a user (even if it's just one of
several signals) sounds like a bad idea, particularly when mobile
devices are involved – it is very common for a phone to switch back
and forth between a wifi connection, and a cellular connection, which
most of the time means switching to a different IP, or even an
entirely different ISP.

Also, passing authentication tokens inside the URI issomething that's
generally better avoided – what if there's some caching proxy
somewhere in between which would cache the full URL, including the
authentication token?

I would strongly recommend using one of the standard authentication
mechanisms instead of trying to roll your own custom solution for
authentication. If it is possible to use the session cookie, then by
all means do that. Otherwise you might want to investigate some form
of token-based authentication, maybe even something based on OAuth, or
perhaps JWT. The Django REST framework, for example, gives you many
options, both built-in, as well as popular third-party extensions.

Cheers,

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 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/20160801211841.GD5430%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: selectively requiring login

[Michal Petrucha]

On Mon, Aug 01, 2016 at 12:17:38PM -0400, Larry Martell wrote:
> I have a view that is accessed both from the browser and from a
> non-browser app. The request from the non browser app come from a
> remote app where the user has already had to login (or they would
> never get to the point where they could cause the request to be sent).
> Is there a way to make login required when the request comes from a
> browser but then not have login required when the request comes from
> the app?

That sounds like a bad idea. Even with the “app”, when a request is
being made, the user has to be authenticated somehow. If you allow
your “app” to access the view without authentication (regardless of
what criterion you pick to determine it is the “app”, be it the
user-agent, referrer, or whatnot), what's to prevent a motivated
attacker from finding the criterion out using a sniffing proxy or some
other tool, and just making the request directly?

Cheers,

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 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/20160801183351.GC5430%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Better style: from django.db import models vs from django.db.models import ...

[Michal Petrucha]

On Mon, Aug 01, 2016 at 05:09:37AM -0700, graeme wrote:
> I have always imported models, and then:
> 
> class Foo(models.Model):
> bar = models.CharField(max_length=100)
> 
> 
> which is what the examples in the django docs do - I copied it when I 
> started using Django and the habit stuck.
> 
> It is a lot less verbose to do:
> 
> from models import Model, CharField
> 
> class Foo(Model):
> bar =CharField(max_length=100)
> 
> because each imported class is used many times in a typical models file. 
> The same apples to forms.
> 
> On the other hand the generic views documentation tends to do things like:
> 
> from django.views.generic.detail import DetailView
> 
> 
> I have increasingly tended to do the same with forms, but not for models, 
> except for things like Q which would be verbose to do otherwise
> 
> Which is better style (and why)?

It is mostly a matter of taste. When you just do 
``from django.db import models``, you can use whatever is defined
inside models by just accessing it through the models module; if you
import things one by one, you have to list all of them explicitly in
the import statement. Either way is fine, using models.IntegerField
and forms.IntegerField just makes it more obvious what kind of
IntegerField it is you're referring to.

The only thing I can think of is that you might sometimes want to
define your own model field, in which you override the default
formfield; in that case, you'd need to have both model fields and form
fields in the same module, and it would be quite chaotic and unclear
which one you're referring to if you cherry-picked classes to import
instead of just importing the modules.

Cheers,

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 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/20160801122834.GB5430%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: django 1.9, migrations certainly don't suck

[Michal Petrucha]

On Fri, Jul 29, 2016 at 08:01:05AM -0700, Jorge Cadena wrote:
> 
> 
> Traceback (most recent call last):
>   File "manage.py", line 10, in 
> execute_from_command_line(sys.argv)
>   File 
> "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", 
> line 353, in execute_from_command_line
> utility.execute()
>   File 
> "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", 
> line 345, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File 
> "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", line 
> 348, in run_from_argv
> self.execute(*args, **cmd_options)
>   File 
> "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", line 
> 398, in execute
> self.check()
>   File 
> "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", line 
> 426, in check
> include_deployment_checks=include_deployment_checks,
>   File 
> "/usr/local/lib/python2.7/dist-packages/django/core/checks/registry.py", line 
> 75, in run_checks
> new_errors = check(app_configs=app_configs)
>   File "/usr/local/lib/python2.7/dist-packages/django/core/checks/urls.py", 
> line 13, in check_url_config
> return check_resolver(resolver)
>   File "/usr/local/lib/python2.7/dist-packages/django/core/checks/urls.py", 
> line 23, in check_resolver
> for pattern in resolver.url_patterns:
>   File "/usr/local/lib/python2.7/dist-packages/django/utils/functional.py", 
> line 33, in __get__
> res = instance.__dict__[self.name] = self.func(instance)
>   File "/usr/local/lib/python2.7/dist-packages/django/core/urlresolvers.py", 
> line 417, in url_patterns
> patterns = getattr(self.urlconf_module, "urlpatterns", 
> self.urlconf_module)
>   File "/usr/local/lib/python2.7/dist-packages/django/utils/functional.py", 
> line 33, in __get__
> res = instance.__dict__[self.name] = self.func(instance)
>   File "/usr/local/lib/python2.7/dist-packages/django/core/urlresolvers.py", 
> line 410, in urlconf_module
> return import_module(self.urlconf_name)
>   File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
> __import__(name)
>   File 
> "/home/ariatel_web/dashboard.ariatel.com.co/dashaboar_ariatel/urls.py", line 
> 20, in 
> from apps.did.views import CountryViewSet, AreasViewSet
>   File "/home/ariatel_web/dashboard.ariatel.com.co/apps/did/views.py", line 
> 15, in 
> from .forms import BuySearchForm
>   File "/home/ariatel_web/dashboard.ariatel.com.co/apps/did/forms.py", line 
> 11, in 
> class BuySearchForm(forms.Form):
>   File "/home/ariatel_web/dashboard.ariatel.com.co/apps/did/forms.py", line 
> 12, in BuySearchForm
> country = forms.ChoiceField(choices=[ (d.country_name, d.country_name) 
> for d in DidCountry.objects.filter(is_active=True) ], required=False)

This line here is the problem – you should never evaluate querysets at
module level, in this case you should either use a function as the
choices argument to ChoiceField, or use a ModelChoiceField.

-- 
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/20160729151636.GY16002%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: django 1.9, migrations SUCK

[Michal Petrucha]

On Fri, Jul 29, 2016 at 07:02:44AM -0700, Jorge Cadena wrote:
> Hi,
> 
> I am dev in django at last 4 years, i missed ./manage.py syncdb, 
> 
> Delete all tables from databases (MariaDB, PostgreSQL) command line from 
> DB, and run python manage.py migrate always same error
> 
> *python manage.py migrate*
> django.db.utils.ProgrammingError: (1146, "Table 
> 'dashaboard_web.did_didcountry' doesn't exist")
> 
> *python manage.py migrate did*
> django.db.utils.ProgrammingError: (1146, "Table 
> 'dashaboard_web.did_didcountry' doesn't exist")
> 
> *python manage.py makemigrations*
> django.db.utils.ProgrammingError: (1146, "Table 
> 'dashaboard_web.did_didcountry' doesn't exist")
> 
> *python manage.py sqlmigrate did 0001*
> django.db.utils.ProgrammingError: (1146, "Table 
> 'dashaboard_web.did_didcountry' doesn't exist")
> 
> *python manage.py migrate --run-syncdb*
> django.db.utils.ProgrammingError: (1146, "Table 
> 'dashaboard_web.did_didcountry' doesn't exist")
> 
> 
> if the tables doesn't exist, why create table new ???
> as, create new tables run command python manage.py migrate ??

If you're getting errors about missing database tables even when you
run manage.py makemigrations, then that would mean you'll get that
same error every time you run manage.py, regardless of what command
you run. makemigrations does not access the database, it only inspects
existing migration files, and compares them to the current model
definitions.

The error you are getting is most likely because you're accessing the
database on import (i.e. somewhere at module level you are making
database queries). If that is indeed the case, then you would get the
exact same error even with the old syncdb. However, it is hard to tell
for sure, since you have not provided the full traceback.

Cheers,

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 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/20160729142428.GX16002%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: static files suspicious operation, os error, and list of paths

[Michal Petrucha]

On Tue, Jul 12, 2016 at 12:40:11AM -0700, Malik Rumi wrote:
> UPDATE:
> 
> I got it back to where runserver comes up and I get no errors, but the 
> staticfiles are still not being served. 
> 
> 
> The paths are in the right *format* to satisfy the STATICFILES_DIR in 
> SETTINGS, and so that they can be *found*, according to debug toolbar, and 
> they *pass* the checks in runserver, collectstatic, and findstatic, but not 
> so they can be *used*. 
> 
> 
> I have to assume that safe_join is still running around somewhere in the 
> background, even though it is now failing silently. 
> 
> 
> I need to make safe join see these paths the same way it saw the single 
> file bootstrap.css when it passed findstatic, but I don't know how to do 
> that. 
> 
> 
> One could ask why I get all those 404's from runserver, but I think that's 
> explained by the fact that safe_join is still blocking them. 
> 
> Ideas?

Could you please post all the settings that are in any way related to
static files in full? That means things like STATICFILES_*, and
everything that's used in those (like BASE_DIR, etc). Please, don't
leave any part of them out. If you are not certain, just post the
entire settings module, only remove secret values.

Also, could you provide the exact URL of a request that is resulting
in a SuspiciousFileOperation, including a full traceback?

Based on the error message you posted in the initial post, it looks
like somewhere, you're calling ``os.path.join(a, b)``, where the
second argument starts with a slash – that might be the reason, but
it's hard to tell whether this is the case, because you haven't shown
us the full settings.

Cheers,

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 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/20160712100323.GK22177%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Error in testing script

[Michal Petrucha]

On Sun, Jul 10, 2016 at 02:25:40PM -0700, Gary Roach wrote:
> On 07/10/2016 01:57 PM, Gary Roach wrote:
> >Hi all;
> >
> >OS Debian Linux KDE desktop
> >Django 1.9
> >Python 3.5
> >
> >Working with tutorial
> >https://docs.djangoproject.com/en/1.9/intro/tutorial05/
> >Writing polls/tests.py script
> >
> >I am consistently getting an error:
> >NameError: name 'create_question' is not defined.
> >
> >The first section of tests.py to throw this error is:
> >def test_index_view_with_two_past_questions(self):
> >"""
> >The questions index page may display multiple questions.
> >"""
> >create_question(question_text="Past question 1.", days=-30)
> >create_question(question_text="Past question 2.", days=-5)
> >response = self.client.get(reverse('polls:index'))
> >self.assertQuerysetEqual(
> >response.context['latest_question_list'],
> >['', ' >1.>']
> >)
> >
> >The code example is in class QuestionMethodTests(TestCase): but is flagged
> >8 times by the editor throughout the code in test.py. The same error pops
> >at run time.
> >
> >The code seems to be identical to the code in the tutorial.
> >
> >All of the errors occur on code lines like:
> >create_question(question_text=" ...
> >
> >All help will be appreciated.
> >
> >Gary R.
> >
> I missed something. The create_question call is a def defined earlier in the
> class.
> 
> def create_question(question_text, days):
> """
> Creates a question with the given `question_text` and published the
> given number of `days` offset to now (negative for questions
> published
> in the past, positive for questions that have yet to be published).
> """
> time = timezone.now() + datetime.timedelta(days=days)
> return Question.objects.create(question_text=question_text,
> pub_date=time)
> 
> this code throws an error : Method 'create_question - polls.tests' should
> have self as first parameter.
> 
> Here again, the code seems to be identical to that in the tutorial. Adding
> self to the def clears this problem but does not clear the rest of the
> errors. The def doesn't seem to be working.
> 
> Gary R

The code snippet in the tutorial does not put ``create_question``
inside the ``QuestionViewTests`` class, but rather at module level.
That makes a difference.

The way it is written in the tutorial, ``create_question`` is just a
global function that you can call from anywhere as it is.

If you put the ``def`` statement inside the class, that means you are
defining a method in that class, in which case you have to treat it as
such. Unless you decorate it as a static method, or a class method,
you can only call it on an instance of that class, and, just like any
other method in Python, will need to take the class instance as its
first argument, most commonly called ``self``.

Does this help clear it up at least a little bit?

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 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/20160711061938.GJ22177%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: how should i make a non downloadable image in my django website

[Michal Petrucha]

On Sat, Jul 09, 2016 at 12:24:25PM +0200, ludovic coues wrote:
> If the image is displayed, the user can use a screen capture tool to get it.
> 
> You can make it harder for your user to get the image by putting a
> transparent image on top of the displayed image. You can put the image
> as a background on a div. You can cut the image in many part and
> display a grid of these image without border so the user can only get
> a piece of the image at a time. You can also play with canvas or put a
> video of the image with a single frame.
> 
> You can also mix all these method.
> Be creative.
> Also, going further that way will give you less readable, harder to
> maintain code and poorer performance as your image need to be
> processed. There is also slight chance your user will hate you and you
> might have trouble to sleep at night.
> 
> If you choose to pursue that way, good luck and have fun :)
> And keep in mind that once you introduce enough difficulty, it will be
> easier to take a screen capture.
> https://xkcd.com/538/

Also keep in mind that as long as the browser is able to somehow
retrieve the image and display it in the page, it is by definition
downloadable (because that's how the browser gets it). So with most of
these approaches, the only thing an interested user would have to do
would be to open the developer tools in their browser, and look at the
log of HTTP requests.

-- 
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/20160709115150.GH22177%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature

Re: Hebrew in Raw Query Like Clause

[Michal Petrucha]

On Thu, Jul 07, 2016 at 11:23:21PM -0500, Art Zemon wrote:
> Hello,
> 
> I have a column in a table that contains Hebrew text. I need to do a query
> with a LIKE clause on the Hebrew text. The query works if I execute the SQL
> directly, either in a SQL window of phpMyAdmin or in a command line mysql
> client. But I cannot get it to work within Django.
> 
> I tried Bible.objects.filter(hebrew_text__contains('דֶּשֶׁא') and I get
> nothing back.

Here, one thing you might want to try is to use django-debug-toolbar's
debugsqlshell, run the query inside that, and take a look at the
actual SQL query generated for that; maybe it will reveal some oddity.

> I tried a raw query in a custom manager:
> 
> class BibleManager(models.Manager):
> def contains_hebrew_word(self, word='דֶּשֶׁא'):
> sql = """select sortkey, book, chapter, verse, hebrew_text
>  from bible_bible
>  where hebrew_text like '%%%s%%' """
> raw_query_set = self.raw(sql, [word])
> result_list = []
> for b in raw_query_set:
> result_list.append(b)
> return result_list
> 
> but I get this error:
> 
> django.db.utils.ProgrammingError: (1064, "You have an error in your SQL
> syntax; check the manual that corresponds to your MySQL server version for
> the right syntax to use near 'דֶּשֶׁא'%'' at line 3")

I may be wrong, but it seems to me that you're using wrong quoting in
that raw query; I think it should be::

select sortkey, book, chapter, verse, hebrew_text
from bible_bible
where hebrew_text like '%%' || %s || '%%'

The DBAPI will already take care of the proper quoting for the string
argument, you just need to properly concatenate it with percent signs
on both sides.

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 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/20160708133324.GG22177%40konk.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature