Jinja2 form rendering for the admin

[Joey Wilhelm]

I know that Jinja2 vs DTL rendering can be a contentious issue at times, so
I want to start from the outset saying that I am not proposing
re-implementing the entire admin in Jinja2 templates!

However, that said, I believe that it is not only possible, but in fact
easy, to get forms to render using the Jinja2 engine in the admin. I've
actually just managed this on my current project at work, and I wanted to
see what thoughts would be for inclusion in core.

According to the documentation[1], "...django.contrib.admin doesn’t include
Jinja2 templates for its widgets due to their usage of Django template
tags."

After some digging, though, it appears that the "spaceless" tag is the only
one in use which is not readily available in Jinja2. And this is only used
in django/contrib/admin/templates/admin/widgets/related_widget_wrapper.html.

So I was able to reimplement this template in Jinja2, minus the spaceless
tag, and I was off to the races. On a few admin pages with large numbers of
inlines, the load time was cut in half or better.

But, of course, there was one more small catch. I had to use the
"TemplateSetting" form renderer rather than the "Jinja2" form renderer,
because I had no way to alter the Jinja2 environment for the form renderer.
The environment I refer to in my settings, however, is pulled almost
verbatim from the documentation for the Jinja2 backend[2]. I only had to
add one thing: i18n. Which turns out to be fairly simple to do with Jinja2
+ Django. I was even able to use the "gettext" and "ngettext" from
django.utils.translation.

So what I'm proposing here boils down to a few pieces:

1) Create jinja2 templates for the admin widgets. I already have one of
these done, and the others look like it may be possible to simply copy them.
2) Document how to add i18n to the Jinja2 environment
3) Perhaps provide a default environment to Jinja2, providing both static
and url, as currently documented in the example Jinja2 environment, along
with i18n. This would provide a better out-of-the-box experience for users,
including being able to set the FORM_RENDERER to Jinja2, and have the admin
Just Work.

So, thoughts? Is this something worth filing a ticket for?

-Joey Wilhelm

[1]: https://docs.djangoproject.com/en/2.0/ref/forms/renderers/#jinja2
[2]:
https://docs.djangoproject.com/en/2.0/topics/templates/#django.template.backends.jinja2.Jinja2

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

Re: Additional PostgreSQL-specific functions

[Joey Wilhelm]

Ping!

Is there any chance of getting some additional guidance on these? I'd love
to get these contributed, if they are welcome!

-Joey Wilhelm

On Fri, Nov 17, 2017 at 1:22 PM, Joey Wilhelm  wrote:

> I did come upon that ticket, but I wasn't sure this necessarily belonged
> as part of it, given that these are not methods which are widely available
> across different engines. That said, I would gladly add them there. I'm
> just eager to spin up a PR or two. :-)
>
> On Fri, Nov 17, 2017 at 1:12 PM, Matthew Pava 
> wrote:
>
>> I wonder if we should put that in this ticket:
>>
>> https://code.djangoproject.com/ticket/28643
>>
>>
>>
>>
>>
>> *From:* django-developers@googlegroups.com [mailto:django-developers@goog
>> legroups.com] *On Behalf Of *Joey Wilhelm
>> *Sent:* Friday, November 17, 2017 2:02 PM
>> *To:* django-developers@googlegroups.com
>> *Subject:* Additional PostgreSQL-specific functions
>>
>>
>>
>> Greetings,
>>
>>
>>
>> Yesterday I opened a ticket[1] for a "RegexpReplace" method for
>> PostgreSQL. After some talk and encouragement over in IRC, I have
>> additionally created a "SubstrFrom" function for PostgreSQL, which allows
>> you to use a regex match in order to extract your substring.
>>
>>
>>
>> So at this point, I have a couple of questions.
>>
>>
>>
>> 1) Are these things which would likely get integrated into core?
>>
>> 2) If so, should I put them into separate tickets or would I be able to
>> combine them into a single?
>>
>> 3) Should they be added to the PostgreSQL specific library? Oracle does
>> have both of these pieces of functionality, but I believe it is the only
>> popular engine aside from PostgreSQL which does.
>>
>>
>>
>> I have the code for both of these implemented in my local project, along
>> with tests, so I would love to contribute them if possible.
>>
>>
>>
>> Thank you!
>>
>>
>>
>>
>>
>> [1]: https://code.djangoproject.com/ticket/28805
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/django-developers/CADBkHd%2Be3GodbKvDFXq0dAgwzs4n%3DFgLG
>> HTYsbhuiQWDOcB64Q%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CADBkHd%2Be3GodbKvDFXq0dAgwzs4n%3DFgLGHTYsbhuiQWDOcB64Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/django-developers/fa1db399bca544eebeeb0b261752ffeb%40ISS1.ISS.LOCAL
>> <https://groups.google.com/d/msgid/django-developers/fa1db399bca544eebeeb0b261752ffeb%40ISS1.ISS.LOCAL?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: Additional PostgreSQL-specific functions

[Joey Wilhelm]

I did come upon that ticket, but I wasn't sure this necessarily belonged as
part of it, given that these are not methods which are widely available
across different engines. That said, I would gladly add them there. I'm
just eager to spin up a PR or two. :-)

On Fri, Nov 17, 2017 at 1:12 PM, Matthew Pava  wrote:

> I wonder if we should put that in this ticket:
>
> https://code.djangoproject.com/ticket/28643
>
>
>
>
>
> *From:* django-developers@googlegroups.com [mailto:django-developers@
> googlegroups.com] *On Behalf Of *Joey Wilhelm
> *Sent:* Friday, November 17, 2017 2:02 PM
> *To:* django-developers@googlegroups.com
> *Subject:* Additional PostgreSQL-specific functions
>
>
>
> Greetings,
>
>
>
> Yesterday I opened a ticket[1] for a "RegexpReplace" method for
> PostgreSQL. After some talk and encouragement over in IRC, I have
> additionally created a "SubstrFrom" function for PostgreSQL, which allows
> you to use a regex match in order to extract your substring.
>
>
>
> So at this point, I have a couple of questions.
>
>
>
> 1) Are these things which would likely get integrated into core?
>
> 2) If so, should I put them into separate tickets or would I be able to
> combine them into a single?
>
> 3) Should they be added to the PostgreSQL specific library? Oracle does
> have both of these pieces of functionality, but I believe it is the only
> popular engine aside from PostgreSQL which does.
>
>
>
> I have the code for both of these implemented in my local project, along
> with tests, so I would love to contribute them if possible.
>
>
>
> Thank you!
>
>
>
>
>
> [1]: https://code.djangoproject.com/ticket/28805
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/CADBkHd%2Be3GodbKvDFXq0dAgwzs4n%
> 3DFgLGHTYsbhuiQWDOcB64Q%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CADBkHd%2Be3GodbKvDFXq0dAgwzs4n%3DFgLGHTYsbhuiQWDOcB64Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/fa1db399bca544eebeeb0b261752ffeb%40ISS1.ISS.LOCAL
> <https://groups.google.com/d/msgid/django-developers/fa1db399bca544eebeeb0b261752ffeb%40ISS1.ISS.LOCAL?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Additional PostgreSQL-specific functions

[Joey Wilhelm]

Greetings,

Yesterday I opened a ticket[1] for a "RegexpReplace" method for PostgreSQL.
After some talk and encouragement over in IRC, I have additionally created
a "SubstrFrom" function for PostgreSQL, which allows you to use a regex
match in order to extract your substring.

So at this point, I have a couple of questions.

1) Are these things which would likely get integrated into core?
2) If so, should I put them into separate tickets or would I be able to
combine them into a single?
3) Should they be added to the PostgreSQL specific library? Oracle does
have both of these pieces of functionality, but I believe it is the only
popular engine aside from PostgreSQL which does.

I have the code for both of these implemented in my local project, along
with tests, so I would love to contribute them if possible.

Thank you!


[1]: https://code.djangoproject.com/ticket/28805

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

Re: Methodology for increasing the number of PBKDF2 iterations

[Joey Wilhelm]

Okay, for good measure, here's with 2.7.7. And yeah, looks like almost 4x
slower.

Python: 2.7.7, Django: 1.10.4
Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes,
on average, 0.3050s
Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes,
on average, 0.3096s
Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes,
on average, 0.3064s
Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes,
on average, 0.3162s
Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes,
on average, 0.3054s

I'm not sure what conclusions this can help with, but at least they are
some solid-ish numbers to work with.

-Joey Wilhelm

On Wed, Jan 4, 2017 at 10:42 AM, Alex Gaynor  wrote:

> Python 2.7.12 will look the same as 3.5.x, they both have the optimized
> implementation. Only 2.7.X where X<8 will have the slow implementation.
>
> If someone was motivated, they could look at the PyPI bigquery and see
> what versions of 2.7 people are using to install django.
>
> Alex
>
> On Wed, Jan 4, 2017 at 12:39 PM, Joey Wilhelm 
> wrote:
>
>> FWIW, here are my own results from that benchmark (I ran each 5 times
>> just to account for any other system activity):
>>
>> Python: 2.7.12, Django: 1.10.4
>> Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification
>> takes, on average, 0.0884s
>> Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification
>> takes, on average, 0.0854s
>> Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification
>> takes, on average, 0.1034s
>> Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification
>> takes, on average, 0.1119s
>> Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification
>> takes, on average, 0.0949s
>>
>> Python: 3.5.2, Django: 1.10.4
>> Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification
>> takes, on average, 0.0876s
>> Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification
>> takes, on average, 0.0857s
>> Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification
>> takes, on average, 0.0872s
>> Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification
>> takes, on average, 0.0847s
>> Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification
>> takes, on average, 0.0874s
>>
>> Python: 3.6.0, Django: 1.10.4
>> Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification
>> takes, on average, 0.0861s
>> Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification
>> takes, on average, 0.0789s
>> Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification
>> takes, on average, 0.0803s
>> Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification
>> takes, on average, 0.0779s
>> Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification
>> takes, on average, 0.0815s
>>
>> This appears to agree with Tobias' results; this is also on a Mac. I can
>> toss in an older Python 2.7 as well if necessary or desired to see the
>> slower implementation. But I think this shows that there's a near enough
>> negligible speed difference in recent Python versions. Aside from perhaps a
>> very slight speedup in 3.6.
>>
>> -Joey Wilhelm
>>
>> On Wed, Jan 4, 2017 at 9:32 AM, Tobias McNulty 
>> wrote:
>>
>>> Here's an interesting tidbit from Alex Gaynor in 2014:
>>>
>>> https://github.com/django/django/commit/6732566967888f2c12ef
>>> ee1146940c85c0154e60#diff-dd9c116fcefaf3916ace2608656311e0
>>>
>>> It's worth noting that, if I'm understanding this correctly, there are
>>> two slow versions of pbkdf2 we have to worry about -- the one bundled in
>>> Django (https://github.com/django/django/blob/6732566967888f2c12efe
>>> e1146940c85c0154e60/django/utils/crypto.py#L142, which is used
>>> pre-2.7.8 and pre-3.4 and claims to be 5x slower) and the Python fallback
>>> for pbkdf2_hmac (which I suppose is used if OpenSSL is unavailable (?) and
>>> claims to be 3x slower).
>>>
>>> Martin, is it possible your version of Python 3 is not linked against
>>> OpenSSL and hence is missing the fast version of pbkdf2_hmac? I haven't had
>>> a chance to try your benchmark yet, but in a quick test I don't see any
>>> difference between Python 3.5.2 and Python 2.7.12 on a M

Re: Methodology for increasing the number of PBKDF2 iterations

[Joey Wilhelm]

FWIW, here are my own results from that benchmark (I ran each 5 times just
to account for any other system activity):

Python: 2.7.12, Django: 1.10.4
Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes,
on average, 0.0884s
Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes,
on average, 0.0854s
Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes,
on average, 0.1034s
Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes,
on average, 0.1119s
Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes,
on average, 0.0949s

Python: 3.5.2, Django: 1.10.4
Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes,
on average, 0.0876s
Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes,
on average, 0.0857s
Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes,
on average, 0.0872s
Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes,
on average, 0.0847s
Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes,
on average, 0.0874s

Python: 3.6.0, Django: 1.10.4
Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes,
on average, 0.0861s
Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes,
on average, 0.0789s
Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes,
on average, 0.0803s
Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes,
on average, 0.0779s
Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification takes,
on average, 0.0815s

This appears to agree with Tobias' results; this is also on a Mac. I can
toss in an older Python 2.7 as well if necessary or desired to see the
slower implementation. But I think this shows that there's a near enough
negligible speed difference in recent Python versions. Aside from perhaps a
very slight speedup in 3.6.

-Joey Wilhelm

On Wed, Jan 4, 2017 at 9:32 AM, Tobias McNulty 
wrote:

> Here's an interesting tidbit from Alex Gaynor in 2014:
>
> https://github.com/django/django/commit/6732566967888f2c12efee1146940c
> 85c0154e60#diff-dd9c116fcefaf3916ace2608656311e0
>
> It's worth noting that, if I'm understanding this correctly, there are two
> slow versions of pbkdf2 we have to worry about -- the one bundled in Django
> (https://github.com/django/django/blob/6732566967888f2c12efee1146940c
> 85c0154e60/django/utils/crypto.py#L142, which is used pre-2.7.8 and
> pre-3.4 and claims to be 5x slower) and the Python fallback for pbkdf2_hmac
> (which I suppose is used if OpenSSL is unavailable (?) and claims to be 3x
> slower).
>
> Martin, is it possible your version of Python 3 is not linked against
> OpenSSL and hence is missing the fast version of pbkdf2_hmac? I haven't had
> a chance to try your benchmark yet, but in a quick test I don't see any
> difference between Python 3.5.2 and Python 2.7.12 on a Mac.
>
> Tobias
>
> On Wed, Jan 4, 2017 at 3:22 AM, Aymeric Augustin  polytechnique.org> wrote:
>
>> Still, this benchmark shows Python 3.5 being 3 times slower than Python
>> 2.7.
>>
>> This is a surprisingly large regression for this time-sensitive function.
>>
>> --
>> Aymeric.
>>
>> On 4 Jan 2017, at 02:06, Tim Graham  wrote:
>>
>> The PBKDF2 speed improvements are in Python 2.7.8 and 3.4+, so you'd need
>> to use Python 2.7.7 or earlier to get the slower version.
>>
>> On Tuesday, January 3, 2017 at 7:56:35 PM UTC-5, Martin Koistinen wrote:
>>>
>>> H, I just tried this using a simple management command to do some
>>> basic benchmarking of password hashing. I made this little package Py2/Py3
>>> compatible. You can find it here: https://github.com/mkois
>>> tinen/hash_benchmark
>>>
>>> (Just install it from the repo into an existing project, then add
>>> 'hash_benchmark' to your INSTALLED_APPS and you now have the management
>>> command `hash_benchmark`.)
>>>
>>> I was expecting to see Py3 out-perform Py2 here by roughly 3X based on
>>> this thread. Instead, I see *the opposite*.
>>>
>>> Python: 2.7.10 (default, Jul 13 2015, 12:05:58) [GCC 4.2.1 Compatible
>>> Apple LLVM 6.1.0 (clang-602.0.53)]
>>>
>>> Django: 1.9.7
>>>
>>> Using cipher: "pbkdf2_sha256" with 100,000 iterations, verification
>>> takes, on average, 0.0955s
>>>
>>> vs.
>>>
>>> Python: 3.5.1 (v3.5.1:37a07cee5969, Dec  5 2015, 21:12:44) [GCC 4.2.1
>>

Re: JsonpResponse subclass of HttpResponse helps easily create JSONP-encoded responses.

[Joey Wilhelm]

Agreed on discouraging (or at least not actively encouraging) the use of
JSONP. Everything I've read on it has started with big "Do not try this at
home!" warnings.

I also very strongly agree on built-in support for CORS, especially
elements of DRF getting more tightly integrated into the core. I think CORS
is an absolutely essential component if Django is going to claim to be able
to support a REST API out of the box, primarily because of the trend of
using domain.com for an app, and api.domain.com for the backend.

-Joey

On Tue, Apr 19, 2016 at 6:59 AM, Tom Christie 
wrote:

> JSONP is essentially a browser hack.
> There have been security issues raised around it, and we I don't believe
> we should encourage its usage by including it in Django core.
> (If anything we *might?* want to consider CORS for built-in support at
> some point.)
> I'd agree with Florian here - I'd rather see this as either a third party
> package, a code snippet that's shared on a blog post, or similar.
>
>   - Tom
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/37f473d0-8654-4774-82aa-adaf23ea49ab%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Making Django more PaaS-friendly

[Joey Wilhelm]

Just to throw another voice in here, I'm currently using django-environ[1],
as mentioned by Sean Brant. In addition, I'm using a settings setup based
on cookiecutter-django[2]. This means having my settings split into
`config.settings.common`, `config.settings.local`,
`config.settings.production`, for example. In common, I have things like
the following:

DATABASES = {
# Raises ImproperlyConfigured exception if DATABASE_URL not in
os.environ
'default': env.db("DATABASE_URL"),
}
EMAIL_BACKEND = env('DJANGO_EMAIL_BACKEND',
default='django.core.mail.backends.smtp.EmailBackend')
# ...etc...

These would obviously propagate up and be used in the production settings.
Then in the local settings, I have things like:

SECRET_KEY = env('DJANGO_SECRET_KEY', default='CHANGEME!!!')
EMAIL_BACKEND = env('DJANGO_EMAIL_BACKEND',
default='django.core.mail.backends.console.EmailBackend')
DATABASES = {
'default': env.db('DATABASE_URL',
default='postgis://django:supersecretpassword@localhost:5432/django'),
}
# ...etc...

I don't know if this is all necessarily the best way to do it, but it has
been working quite well for me. Everything is read out of a .env file, and
I provide a template.env file in my project to show which values need to be
set in there. `DJANGO_SETTINGS_MODULE` defaults to production, so that
missing environment keys will raise alarms by default, and then when
possible, those keys become optional in development settings.

-Joey

[1]: https://github.com/joke2k/django-environ
[2]: https://github.com/pydanny/cookiecutter-django

On Mon, Apr 11, 2016 at 10:39 AM, Curtis Maloney 
wrote:

> Just want to throw my 3c in here...
>
> Firstly, for reference, I wrote django-classy-settings to help with
> various settings related problems, one of which being env-based setting.
>
> https://github.com/funkybob/django-classy-settings
>
> As my env decorators are written to be class properties, they don't quite
> fit this discussion... however, things to consider:
>
> 1. All env vars can have a fallback value (the method in my case)
> 2. You can mark an env var as not having a fallback value, and it will
> raise an error at start up if not set.
> 3. Non-trivial value types are not easy.
>
> The URL series of settings helpers deal with many of these cases fairly
> well, as they allow us to specify a backend (protocol), username, password,
> host, port, and positional and keyword arguments.
>
> Registering more protocols is actually quite easy, all told.
>
> However, it becomes tricky when we allow multiples, such as database and
> cache backends.  Do we settle on, for instance, a pattern of
> "DJANGO_DATABASE_{name}="? Or some other scheme?
>
> Email settings are certainly another big one, IME... as well as AWS keys...
>
> --
> C
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/570BE142.3000209%40tinbrain.net
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Should contrib.auth include support for 2fa out of the box?

[Joey Wilhelm]

Fwiw, 2fa is on my short list of things to implement into my current
project. It's a fairly important feature to me, as this is a financial
project. And that particular implementation is precisely what I was looking
to use. I would happily contribute money and/or time toward this
implementation, especially if there was a happy upgrade path from Bouke's
library.
On Oct 26, 2015 15:47, "Josh Smeaton"  wrote:

> Having pluggable 2fa backends is a great idea.
>
> Many sites that allow 2fa have it as an option per user. I would think
> Django would allow the same. Allow admins to force 2fa, or allow Users to
> choose if they'd like it enabled.
>
> There'd have to be ORM/Model support (presumably) for user choices. A
> migration may be necessary, or just a completely separate table. Just
> things to consider.
>
> Cheers
>
> On Tuesday, 27 October 2015 04:30:25 UTC+11, Donald Stufft wrote:
>>
>> I agree with Alex, no idea about that particular implementation though.
>> It supports a lot of different implementations of two factor, though I
>> suspect Django wouldn’t need all of those things. I think it would be
>> reasonable to define something like auth_backends, but for 2fa and just
>> ship u2f and TOTP by default.
>>
>> On October 26, 2015 at 1:22:54 PM, Tim Graham (timog...@gmail.com)
>> wrote:
>> >
>> >
>> > On Trac [1], Alex says, "Django did a tremendous service to its users
>> by
>> > making strong password hashing be the default. The world is pushing
>> > forward, and now 2fa is the next standard that many sites fail to meet.
>> > Django should include support for 2fa out of the box, ideally with
>> support
>> > for both u2f and TOTP (Google Authenticator)."
>> >
>> >
>> > Doing a quick search, I found
>> > https://github.com/Bouke/django-two-factor-auth as a possible existing
>> > implementation that might be a starting point if we decide to integrate
>> > something. What do you think? One sticking point could be that it uses
>> a
>> > ThreadLocals middleware. I didn't look to see how "necessary" that is.
>> >
>> >
>> > [1] https://code.djangoproject.com/ticket/25612
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "Django developers
>> > (Contributions to Django itself)" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to django-develop...@googlegroups.com.
>> > To post to this group, send email to django-d...@googlegroups.com.
>> > Visit this group at http://groups.google.com/group/django-developers.
>> > To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/5ae7be8e-949c-4074-b613-04ca2a62fed8%40googlegroups.com.
>>
>> > For more options, visit https://groups.google.com/d/optout.
>> >
>>
>> -
>> Donald Stufft
>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
>> DCFA
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/fe9102ce-a136-40f9-a95e-0254ebc340e2%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [GSOC] Multi-DB Status Update

[Joey Wilhelm]

Hi Alex,

On Fri, May 8, 2009 at 16:04, Alex Gaynor  wrote:

> Hello All,
>
> I've spent the past week at EuroDjangocon, and as such I've had the
> opportunity to discuss multi-db stuff with a bunch of very smart people.
> Simon and I resolved the issue of DSNs vs. dicts (as long as Simon can
> dynamically add a new DB he's happy).  Otherwise nothing has changed.
>

Glad to hear this issue got resolved. After my previous email stating that I
preferred DSNs, I actually tried for some time to come up with a valid
reason for it, and I think it just came down to the fact that I preferred
this shed to be painted red. No good reason other than that. I have to
second being happy as long as I can add them dynamically.

I want to be certain that my particular use case will be covered in the
design considerations here though, as what I've been doing seems to be
somewhat different than other scenarios I've proposed. I'm fully aware that
I'm twisting Django in ways that it was never meant to be, but this is the
scenario I'm looking at:

Currently, we have a large data warehouse sitting in SQL Server 2000. This
is fine, and Ramiro's backend works wonderfully for connecting to this.
That's where the ease ends, however. We're playing around with moving to two
completely separate databases, even using different engines. Most likely
PostgreSQL for our OLTP databases and Infobright (at least that's the color
of the week) for our OLAP databases. On each of these servers, we will have
a separate database for each of our clients, but the table/view layouts will
be similar across all databases. While we could run a separate Django
instance per client, that's pretty sub-optimal. So, this rules out the idea
of having the database assignment directly on the model, obviously. This
also complicates matters in that we will be using two separate database
engines with very different interactions.

These may be things which have already been taken into consideration... and
if so, great! Hopefully this isn't too far off in left field (and actually
made sense...).

Thanks!

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Multi-DB

[Joey Wilhelm]

On Wed, Apr 29, 2009 at 16:03, Simon Willison wrote:

> 3. (really nutty one this) - a very high scale situation where an
> application is partitioned across hundreds of databases, which each
> one having the same set of tables. This is how WordPress-MU works (as
> used by wordpress.com), with every blog getting its own duplicate set
> of tables -  and it's surprisingly effective.
>

I would have to agree for precisely this reason. I already have a (perhaps
not extremely high scale, but certainly Big Data) project using the
implementation Simon described. Specifically, I have my Django-specific
tables in a PostgreSQL database on one server, and then I have Django
connecting to one of many MS SQL databases on two other machines, dependent
on which client's data is being viewed.

Obviously this took a good bit of hackery to get it working properly, and
there are still a few issues buried deep within, but I did end up utilizing
DSNs for determining and establishing the appropriate connections.

This does, however, bring up the point of interacting with multiple database
engines at once, which is not exactly configurable for a DSN. In general
though I give a big +1 for DSNs.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: How do you handle cascading deletes in your production apps?

[Joey Wilhelm]

Zach,

You can always run custom delete operations if you want to work around the
built in cascading. Take a look at the following example to see how you can
do that: http://dpaste.com/92116/

Also, note that there is a ticket to add support for ON UPDATE and ON DELETE
clauses to Django[1]. Working on fixing up tickets is nearly always
encouraged. :)

-Joey

[1] http://code.djangoproject.com/ticket/7539



On Wed, Dec 10, 2008 at 07:25, AcidTonic <[EMAIL PROTECTED]> wrote:

>
> Currently the cascading delete functionality requires many users to
> change how their app works slightly to accommodate this "feature".
>
> I'm curious how people are disabling or working around this aspect of
> django.
>
> I've heard many people are implementing custom delete() methods on the
> model class.. But after reading "http://docs.djangoproject.com/en/
> dev/topics/db/queries/#deleting-objects"
> I found a nice little gotcha.
>
> "Keep in mind that this will, whenever possible, be executed purely in
> SQL, and so the delete() methods of individual object instances will
> not necessarily be called during the process. If you've provided a
> custom delete() method on a model class and want to ensure that it is
> called, you will need to "manually" delete instances of that model
> (e.g., by iterating over a QuerySet and calling delete() on each
> object individually) rather than using the bulk delete() method of a
> QuerySet."
>
> So before we had a bulk delete and now to get around functionality we
> dont want, we have to lose bulk deletes and do them one at a time?!?
>
> I'm building an application to track IP addresses on many corporate
> networks with a single subnet having around 65535 rows for IP
> addresses. Now this app has thousands of those subnets which means
> I have millions of rows for IP addresses.
>
> Since they have relationships to the parent subnet, switchports,
> devices, contacts, locations, applications etc. These relationships
> need to be cleared before removing the IP, because nothing else is
> supposed to get deleted.
>
> When before I could delete 5 subnets which removed a few hundred
> thousand rows in a couple seconds, now to delete a single subnet takes
> upwards of 5 minutes using the "for query in queryset: query.delete()"
> method.
>
> So unless I'm missing something it would appear django is crippling
> any application not wanting a cascading delete Since this is an
> inventory style application any missing data is extremely bad. Waiting
> 5 minutes for something that used to take a few seconds is also
> unacceptable.
>
> I'm seeking all suggestions or ideas how to keep my other models from
> getting deleted, without crippling my applications performance.
>
> Please advise,
> Zach
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: Composite Foreign Keys

[Joey Wilhelm]

Hanne,

I ran into that exact problem myself and filed the following ticket related
to the issue: http://code.djangoproject.com/ticket/9519

I also found that you could run your own delete operation through the ORM,
however, to work around this. It's more work and certainly not in line with
DRY or any of the normal sensibilities... but it does at least work. Here's
an example of that, built off the example in the ticket:
http://dpaste.com/92116/

On Wed, Nov 19, 2008 at 05:07, Hanne Moa <[EMAIL PROTECTED]> wrote:
>
> Funny thing though, got a manytomany-table without a primary key: I
> can add a new row easily enough, the only problem is in delete()-ing
> specific rows, since that seems to use the primary key. So I clear()
> and re-add instead of delete()-ing, since that doesn't use the primary
> key. Fragile, but it beats doing the puppy-eyes to the DBA.
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Dynamic SITE_ID (again)

[Joey Wilhelm]

Yes, I did run into that issue. This is what I ended up with:
http://dpaste.com/89143/

Now I'm not saying that my code is 100% working, or that I recommend using
it; that's why it's up on dpaste and not DjangoSnippets. Personally, I hate
this solution but it at least seems to be working for now. I haven't had
too much chance to do extensive testing yet though. Also, as has been
pointed out in the past, this is simply -not- the right way to do it.

On Thu, Nov 6, 2008 at 10:16, Joe <[EMAIL PROTECTED]> wrote:

>
> Joey Wilhelm wrote:
> > I also found a snippet which implements something similar, here:
> > http://www.djangosnippets.org/snippets/1099/
> > Of course, the snippet didn't really work right and had to be beaten
> > into submission to even give the illusion of working.
>
> I also referred to that snippet for a solution to the Dynamice SITE_ID
> problem. Was this the only problem you had:
>
> http://www.djangosnippets.org/snippets/1099/#c1442
>
> or did you run into other problems? Were you able to solve that one?
>
> So far, it seems to work OK for me. I haven't used CurrentSiteManager()
> yet though.
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Dynamic SITE_ID (again)

[Joey Wilhelm]

I would like to bring up the topic discussed both in this ticket:
http://code.djangoproject.com/ticket/4438 and here in this group as
well: 
http://groups.google.com/group/django-developers/browse_thread/thread/4125cb192c72ed59/7a9f379f5e5b9090

I also found a snippet which implements something similar, here:
http://www.djangosnippets.org/snippets/1099/
Of course, the snippet didn't really work right and had to be beaten
into submission to even give the illusion of working.

Obviously, as discussed previously, none of these options are optimal.
They all have their fair share of issues, and there really should be a
better way to go about it.

Two of these options were mentioned by Malcolm in the aforementioned
thread; thread-local settings, or a more dynamic site object.

I found it odd that this discussion fell flat after a very short
period, over a year ago. Personally, this was a feature which I
initially assumed Django supported, simply because it seemed like such
an obvious one to me. Now I find myself struggling to get a project
working how I want due to the lack of what, in my mind, should be a
readily available feature.

Now I know from reading all of the previous discussions that this
really isn't such an easy implementation, but given the state of
Django today, how much work would really be involved? For that matter,
what design direction would be the preferred one?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.0.1 release blockers?

[Joey Wilhelm]

I would like to suggest the following:
http://code.djangoproject.com/ticket/9245
http://code.djangoproject.com/ticket/6710

They both have fully functional patches... although granted the second has
no tests.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Composite Primary Keys

[Joey Wilhelm]

That would be great. The project I am working on now won't be doing anything
too terribly complex just yet; I mainly need the admin support to make my
life a little easier.

As to the API, I saw several proposals earlier along on this thread, but
obviously nothing solid. Did anything ever come from DjangoCon on this
topic? What issues still need to be addressed in this design?

On Thu, Oct 30, 2008 at 13:46, David Cramer <[EMAIL PROTECTED]> wrote:

> It allows you to use them, automatically creates them, and has some of the
> admin handling done. However, there's still no API design around
> multi-column fields (no one seems to want to talk about it) so I'm pretty
> much stopped working on it.
>
> e.g. You can't say field1 = this, field2 = that, and then say compositekey
> = field1,field2 you instead are forced to do key1=blah, key2=blah in all
> your lookups, and no easy foreignkey properties.
>
> I'm running this on production environments, so it works fine, but I can up
> SVN and fix any conflicts and post a patch again.
>
> --
> David Cramer
> Director of Technology
> iBegin
> http://www.ibegin.com/
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Composite Primary Keys

[Joey Wilhelm]

David,

What is the current status of this patch? I'm starting up a new
project which pretty much desperately needs this support as well. I
could work around it, but the thought of adding AutoFields to all of
these models which really -do not- need them, makes me a bit ill.

I would be more than willing to help test your implementation if there
is anything usable yet. This is one of the pieces that's getting me
all twitchy waiting for it.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Ticket #9405 - Thoughts?

[Joey Wilhelm]

This patch was one essential step I had to make in an application I am
developing to be able to connect to both PostgreSQL and MS SQL databases
concurrently. My Django configuration is stored in PostgreSQL and therefore
is where django.db.connection points. I am accessing data on the MS SQL
servers, however, through a custom manager. When performing database
operations on the MS SQL connections, the operations class for PostgreSQL
would instead be called, because there are several things in
DatabaseOperations which reference django.db.connection. With this patch,
everything is moved to use self.connection instead and the world is happier.
:)

Malcolm said in his response to the ticket, "It's not immediately clear that
it's the right approach for multiple database support." However, I believe
that I'm not offering a particular solution or approach to fully
implementing multiple database support; this is simply something which will
make the integration easier regardless of what approach is decided upon.
It's already been proven to work in my own case, and I can't see any reason
it wouldn't work with any other implementation.

On Thu, Oct 30, 2008 at 11:53, Jacob Kaplan-Moss <[EMAIL PROTECTED]
> wrote:

>
> On Thu, Oct 30, 2008 at 11:42 AM, Joey Wilhelm <[EMAIL PROTECTED]>
> wrote:
> > The patch itself is [...] potentially very helpful.
>
> How so? Be specific: we don't add things to Django because of their
> "potential" use; we add things because of actually problems. What,
> exactly, would this patch let you do that you can't currently?
>
> Jacob
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Ticket #9405 - Thoughts?

[Joey Wilhelm]

I wanted to bring this up here on the mailing list, as I doubt much
discussion will take place on a ticket which was closed as "wontfix". I
added a comment to the ticket after it was closed as to my reasoning behind
the ticket and associated patch, and I wanted to see what other people have
to say on the subject.

The patch itself is small, harmless (afaict) and potentially very helpful.

Any input is welcome!

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: user-friendly API for multi-database support

[Joey Wilhelm]

Hello all,

I just wanted to toss in my own $0.02 for my particular use case and
my experiences thus far. For all around ease, this is a copy of a
comment I made on ticket #1142 yesterday:

What is the current status on this issue? There doesn't appear to have
been any visible movement in several months now, and this is something
which would be very useful in a project I'm working on. I have a
slightly different use case than the previously mentioned ones,
however... and I'm sure it's not an entirely common one, but perhaps
something to take into consideration.

The company I work for is sitting on a fairly large data warehouse for
a number of clients. Each client has their own database, with a common
schema, on one of two MS SQL 2k servers. In the near future, we will
hopefully be moving some of these clients onto a PostgreSQL server
(and in the distant future, it would be nice to move towards
Greenplum; although that should be transparent with psycopg2, afaik).
In addition, there is a separate database already running on the
PostgreSQL server, which stores configuration parameters and which I
am using for the Django system tables.

On every page load, I need Django to connect to database 'A' on the
PostgreSQL server for any Django specific operations, then connect to
an arbitrary database on either of the MS SQL servers, depending on
which of our clients' data is currently being viewed. From what I've
seen so far in the discussion in this ticket and on
MultipleDatabaseSupport, this doesn't sound like it would likely be a
supported scenario, as the connection to be used is determined
dynamically, rather than a static connection chosen per model. In my
case, all models apply across all database connections.

Now, I have made this work thus far with my own connection manager
(http://dpaste.com/hold/84458/) but using it is somewhat kludgy and
I'm sure it's far from a full implementation. I also had to apply a
hack (http://code.google.com/p/django-pyodbc/issues/detail?id=18) to
django-pyodbc and apply a pending patch (#6710) to Django in order to
get it to work. Here is an example of why it in use: 
http://dpaste.com/hold/84465/


Having read through the posts on this thread, it appears that this was
actually (somewhat) one of the mentioned approaches. As mentioned in
one posting, however, this violates DRY in many ways. In my case
however, this may be a necessity, unless I find some way to determine
the connection in a piece of middleware, then make that connection
globally available (without overriding the 'system'
django.db.connection object).

Now, the above is all good and well, and this has been working fairly
well for me thus far... but I just hit one big stumbling block today.
In fact, it's pretty much a 50 ft. brick wall in my path. The problem
is in the get_db_prep_value() function for some field types. Line 609
of django/db/models/fields/__init__.py is the case I am running into
at the moment. It is specifically referring to django.db.connection,
regardless of what connection may have been tossed around between
Query objects. Now even in most multi-db cases, this wouldn't cause a
problem, because it's just asking the db driver how to convert the
data. In my case, however, django.db.connection is a psycopg2
connection, while I'm actually querying from a pyodbc connection. This
tends to make Django fairly unhappy. In fact, this prompted one of the
most confusing Python error messages I have seen to date: "TypeError:
* wants int"

Looking through this same fields file, it appears that there are a
great many direct references to the global connection object, and I'm
not entirely sure how to work around this at the moment, aside from
perhaps passing the connection to the Field object.

Any input, suggestions, criticism, etc are welcome.

--Joey Wilhelm

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---