It's not that hard to just set up a OneToOneField back to User, and
use signals to automatically create a User when you create your own
User/Profile. Then you can still make use of 3rd party apps that rely
on contrib.auth or contrib.sessions, and also make use of groups from
contrib.auth, etc.
Che
Yes, ABORT + DISCARD should do it for postgres (or ABORT; RESET ALL; SET
SESSION AUTHORIZATION DEFAULT if pg < 8.2)
Cheers,
Florian
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.g
Hi,
On Friday, February 17, 2012 11:08:40 PM UTC+1, Cal Leeming [Simplicity
Media Ltd] wrote:
>
> Could you elaborate on this a bit more? And would this affect MySQL?
Well there isn't much more to it than a "ABORT; DISCARD ALL" at the end of
the session to discard changes and clean (abort) and
On Fri, Feb 17, 2012 at 4:58 PM, Florian Apolloner
wrote:
> This approach has quite a few issues on it's own, eg for postgres if the
> transaction is broken all following requests will raise a 500. You have to
> at least reset the connection state to something useable again.
what about not closin
On Fri, Feb 17, 2012 at 9:58 PM, Florian Apolloner wrote:
>
>
> On Friday, February 17, 2012 10:11:57 PM UTC+1, Cal Leeming [Simplicity
> Media Ltd] wrote:
>>
>> # Apparently this will stop many connections to MySQL
>> from django.core import signals
>> from django.db import close_connection
>> si
On Friday, February 17, 2012 10:11:57 PM UTC+1, Cal Leeming [Simplicity
Media Ltd] wrote:
>
> # Apparently this will stop many connections to MySQL
> from django.core import signals
> from django.db import close_connection
> signals.request_finished.disconnect(close_connection)
>
This approach
Hi all,
Wwe actually put a patch into production about 2 weeks ago, which seems to
have reduced the connection count, whilst being stable and not having any
inconsistency problems.
# Apparently this will stop many connections to MySQL
from django.core import signals
from django.db import close_co
On 17 February 2012 20:22, Carl Meyer wrote:
>
>> The second is class_view_decorator, to apply classic view decorators
>> to the newer class-based views:
>>
>> @class_view_decorator(never_cache)
>> @class_view_decorator(login_required, login_url='/my-login')
>> @class_view_decorator(permission_req
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Tobia,
Thanks for taking the time to propose these additions. Comments below:
On 02/17/2012 11:04 AM, Tobia Conforto wrote:
> The first is an updated version of method_decorator, made to accept
> additional arguments and pass them to the origin
Hi all,
I ran my project's tests today using the new beta and was surprised
when one innocuous-looking test failed because the expected English
validation error string didn't match the returned Slovak equivalent.
It turns out that this view is accessible with URL whose path begins
with "/sl/". Ti
On Feb 17, 12:07 pm, Yuval Adam wrote:
> Hey all,
>
> Can anyone here please help me out with understanding the status of
> ticket #12978?
> (https://code.djangoproject.com/ticket/12978)
>
> It's a 2 year old feature request, fulfilled with a patch + tests +
> docs by me, several months after.
> I
Hello
As a happy user of the class-based views, I wrote a couple of higher-level
decorators to make it easy to apply all the standard decorators to them.
The first is an updated version of method_decorator, made to accept additional
arguments and pass them to the original decorator:
class MyVi
+1 on using a Dynamic Stylesheet Language for the Admin.
Would there only be one flavor? LESS or SCSS? Does it matter? Would
providing a means to implement either be necessary?
On Feb 16, 3:56 pm, Juan Pablo Martínez wrote:
> The topic is: start using less (and bootstrap!)
> Please, no more
Hey all,
Can anyone here please help me out with understanding the status of
ticket #12978?
(https://code.djangoproject.com/ticket/12978)
It's a 2 year old feature request, fulfilled with a patch + tests +
docs by me, several months after.
It has been in "triage" ever since.
Unfortunately, I do
It's not just the django.contrib apps you lose, it's any app that uses a
ForeignKey
to users. Which can be a lot of them.
On Friday, February 17, 2012 at 5:13 AM, Jonathan Slenders wrote:
>
> On 16 fév, 13:05, Tom Evans (http://googlemail.com)> wrote:
> > 75 isn't large enough these days f
On 16 fév, 13:05, Tom Evans wrote:
> 75 isn't large enough these days for either email or username. We run
> a patched version of django for some time that has changed both these
> fields to 255 characters in order to accommodate the needs of our
> users. See RFC 3696.
This and other issues made
On 17-02-12 00:06, Carl Meyer wrote:
On 02/16/2012 03:35 PM, Reinout van Rees wrote:
> Partially related question: several tickets have a pull request on
> github instead of an svn patch. Is that enough? I assume a real svn
> patch is better?
A link on the ticket to a github branch or pull r
17 matches
Mail list logo
