Re: Custom user models don't like non integer primary keys.

[Eric Hutchinson]

Sorry for disappearing there.

I didn't think a full trace was necessary, russ nailed that particular 
instance. As a user of django, I don't think for 1.5 that you need to 
change the behavior of views. It just blind sided me that the custom auth 
model needed an integer ID and it should be added to the docs before 
release. 

It'd be super nice if it worked with other field types, but I don't see it 
being a big deal if it's documented as being that way.

On Tuesday, November 6, 2012 6:07:14 PM UTC-5, Russell Keith-Magee wrote:
>
> Hi Eric,
>
> Although the full stack trace would confirm it, I think I can guess what 
> the problem is here -- it's the mechanism for generating reset tokens. 
>
> If you dig into the token generation (and reversal) mechanisms, they use 
> int_to_base36 and base36_to_int to convert the user's primary key into 
> something that can be used as a reversible, text-based identifier of the 
> user object that isn't the literal identifier itself. This identifier is 
> then used as part of the password reset token (along with a timestamp 
> component and a component based on the last login timestamp)
>
> A base36 encoding of an integer produces a nice reversible alphanumeric 
> representation of the integer primary key that can be used in this reset 
> token. 
>
> So, yes -- non-integer primary keys will have a problem with any of the 
> password reset or account activation logic. These should (he says, 
> hopefully) be the only views that are affected.
>
> One of the big features for Django 1.5 is the introduction of swappable 
> user models. However, even with that change, we've maintained the 
> requirement that the User model has an integer primary key
>
> That said, I'm not personally opposed to dropping this requirement -- we 
> just need to find a way to abstract the PK-dependent tokenization part in a 
> useful way. As an initial thought, this is something that we could abstract 
> out to the token generator API; the token generator is already customisable 
> in the password reset views. However, I'm certainly open to other 
> approaches.
>
> Yours,
> Russ Magee %-)
>
> On Wed, Nov 7, 2012 at 3:19 AM, Jacob Kaplan-Moss 
>  > wrote:
>
>> Hey Eric --
>>
>> Can you post the full traceback instead of just the snippet? Without
>> that it's not clear whether this is a bug or just a consequence of
>> defining your own custom user model. As the documentation notes:
>>
>> """
>>
>> As you may expect, built-in Django's forms and views make certain
>> assumptions about the user model that they are working with.
>>
>> If your user model doesn't follow the same assumptions, it may be
>> necessary to define a replacement form, and pass that form in as part
>> of the configuration of the auth views.
>> """
>>
>> So it might be the case that you just need to be customizing more
>> stuff to deal with your special model. Or not, but we probably need
>> more info to decide either way.
>>
>> Jacob
>> Jacob
>>
>>
>> On Tue, Nov 6, 2012 at 12:43 PM, Eric Hutchinson
>>  wrote:
>> > I've been playing with custom user models. Something i've found is that
>> > trying to use the django-extensions uuidfield as a primary key doesn't 
>> seem
>> > very usable at the moment.
>> >
>> > Many of the built in auth views, specifically password reset, assume an
>> > integer field here.
>> >
>> > /lib/python2.7/site-packages/django/utils/http.py", line 187, in
>> > int_to_base36
>> > raise TypeError("Non-integer base36 conversion input.")
>> > TypeError: Non-integer base36 conversion input.
>> >
>> >
>> > Also, in the admin when creating a new user with the example admin setup
>> > from the docs, even though it would seem to have no reason to i get it
>> > trying to redirect to /app/model/(integer)/ when the id is clearly a 
>> uuid.
>> >
>> > I know this isn't that helpful, but I don't know if this is just 
>> something
>> > you might want to warn about in the docs, or if this is something you 
>> want
>> > to fix in the built-in auth views, or what.
>> >
>> > --
>> > 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.google.com/d/msg/django-developers/-/VHk_gOF8DmEJ.
>> > To post to this group, send email to 
>> > django-d...@googlegroups.com
>> .
>> > To unsubscribe from this group, send email to
>> > django-develop...@googlegroups.com .
>> > For more options, visit this group at
>> > http://groups.google.com/group/django-developers?hl=en.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to 
>> django-develop...@googlegroups.com .
>> For more options, visit this group at 
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
>

-- 
You 

Re: Class based views: A standard hook for http-method-independent code

[Aaron Merriam]

That pattern has nasty side-effects.  It can be used in some cases but it 
fails in most.

On Friday, November 9, 2012 8:28:47 AM UTC-7, Daniel Sokolowski wrote:
>
>   I’ve done the below in the past, the only issue with that is if you 
> have side effects in parent’s dispatch you don’t want executed but you 
> would also run that risk if you had an initialize() method work flow; in 
> the end I find dispatch() is enough in my experience. 
>  
> def dispatch(self, request, *args, **kwargs):
> parent_dispatch_return = super(Class, self).dispatch(request, *args, 
> **kwargs)
> ...my code based on values based on the super call...
> return parent_dispatch_return
>   
>  *From:* Jordan Hagan  
> *Sent:* Friday, November 09, 2012 12:37 AM
> *To:* django-d...@googlegroups.com  
> *Subject:* Re: Class based views: A standard hook for 
> http-method-independent code
>  
> Hey Russ, 
>  
> The main point of concern which I think you may be missing is that 
> self.kwargs and self.args are set inside dispatch, so using other mixins 
> that require self.kwargs and self.args to be set (most do) will not work, 
> without doing:
>  
> def dispatch(self, request, *args, **kwargs):
> self.args = args;
> self.kwargs = kwargs
> self.init()
> return super(Class, self).dispatch(request, *args, **kwargs)
>  
> Which isn't very tidy, to me having self.args and self.kwargs be set twice 
> (once in my overridden dispatch method, and once in the original dispatch) 
> feels wrong. I can't give you a good reason for it, it just feels bad every 
> time I do it. The only way to work around this is to override dispatch 
> without calling the original, and essentially duplicate the original 
> dispatch method with an init call added in.
>  
> Cheers,
> Jordan
>   
> On Fri, Nov 9, 2012 at 6:25 PM, Russell Keith-Magee <
> rus...@keith-magee.com > wrote:
>
>>
>>
>>  On Fri, Nov 9, 2012 at 1:05 PM, Aaron Merriam 
>> > > wrote:
>>
>>> Without setting request, args, and kwargs on on the view instance (which 
>>> is done during the base dispatch view), anything in the view that assumes 
>>> these values are present cannot run.   
>>>  
>>> Most of my views end up with functions which retrieve an object and then 
>>> do some basic validation to ensure that a user has permissions, or that the 
>>> object is valid in some fashion, or that some set of conditions is met 
>>> prior to allowing any method call to happen.  
>>>  
>>> I have found that without this init method, the vast majority of my 
>>> views end up re-writing dispatch which includes the super call.  This is 
>>> especially annoying when you have to compare some aspect of the requesting 
>>> user with an object that must be looked up with something from args or 
>>> kwargs.  My view often already has this machinery built in, but it can't 
>>> function without dispatch setting request, args, and kwargs, so to 
>>> accomplish my check, I have to duplicate the lookup code in my dispatch 
>>> method.
>>>  
>>> I don't propose mine is the best solution, but I know that it is 
>>> non-intrusive, simple, and covers my use cases well.  It is also simple to 
>>> accomplish any number of things since `init` merely needs to return a falsy 
>>> value to allow the request to pass on through, raise an exception if that 
>>> type of failure is desired, or return a response of it wants to hijack the 
>>> view entirely.
>>>
>>>  
>> I'm starting to feel like I'm incredibly dense, because I still don't 
>> understand what your use case *is* - or, at least, why what your proposing 
>> provides any significant advantages over what you can do using basic Python 
>> inheritance techniques.
>>  
>> Specifically, I still can't see why:
>>  
>>  class MyView(View):
>>  def  dispatch(self, request, *args, **kwargs):
>> init()
>> return super(MyView, self).dispatch(request, *args, **kwargs)
>>  
>> def init():
>> # your init logic here
>>  
>> is superior to the solution provided by using basic Python inheritance:
>>  
>> class MyView(View):
>>  def  dispatch(self, request, *args, **kwargs):
>> # your init logic here
>> return super(MyView, self).dispatch(request, *args, **kwargs)
>>  
>>  You have exactly the same workflow, and exactly the same order of 
>> operations. You don't need to document any special CBV-specific API -- 
>> e.g., when/how init() will be invoked, and with what assumptions about the 
>> request environment can be made -- and you don't have to incur the overhead 
>> of a function call (ok - the overhead is tiny, but let's not pretend it's 
>> zero).
>>  
>> So - can someone explain to me what the advantage is? Why is this init() 
>> method needed?
>>  
>> Yours,
>> Russ Magee %-)
>>  
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>>  To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> To 

dumpdata with custom auth model

[Christian Jensen]

Hi,

Has anyone run into an issue where dumpdata refers to the old auth model
and tries to dump its data?

Here is what I am encountering:

DEBUG 2012-11-09 11:49:46,363 util 8457 140488053692160 (0.002) SELECT
"auth_user"."id", "auth_user"."password", "auth_user"."last_login",
"auth_user"."username", "auth_user"."first_name", "auth_user"."last_name",
"auth_user"."email", "auth_user"."is_staff", "auth_user"."is_active",
"auth_user"."is_superuser", "auth_user"."date_joined" FROM "auth_user"
ORDER BY "auth_user"."id" ASC; args=()

CommandError: Unable to serialize database: relation "auth_user" does not
exist
LINE 1: ...r"."is_superuser", "auth_user"."date_joined" FROM "auth_user...



-- 

*Christian Jensen*
724 Ioco Rd
Port Moody, BC V3H 2W8
+1 (778) 996-4283
christ...@jensenbox.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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Class based views: A standard hook for http-method-independent code

[Daniel Sokolowski]

I’ve done the below in the past, the only issue with that is if you have side 
effects in parent’s dispatch you don’t want executed but you would also run 
that risk if you had an initialize() method work flow; in the end I find 
dispatch() is enough in my experience. 

def dispatch(self, request, *args, **kwargs):
parent_dispatch_return = super(Class, self).dispatch(request, *args, 
**kwargs)
...my code based on values based on the super call...
return parent_dispatch_return

From: Jordan Hagan 
Sent: Friday, November 09, 2012 12:37 AM
To: django-developers@googlegroups.com 
Subject: Re: Class based views: A standard hook for http-method-independent code

Hey Russ, 

The main point of concern which I think you may be missing is that self.kwargs 
and self.args are set inside dispatch, so using other mixins that require 
self.kwargs and self.args to be set (most do) will not work, without doing:

def dispatch(self, request, *args, **kwargs):
self.args = args;
self.kwargs = kwargs
self.init()
return super(Class, self).dispatch(request, *args, **kwargs)

Which isn't very tidy, to me having self.args and self.kwargs be set twice 
(once in my overridden dispatch method, and once in the original dispatch) 
feels wrong. I can't give you a good reason for it, it just feels bad every 
time I do it. The only way to work around this is to override dispatch without 
calling the original, and essentially duplicate the original dispatch method 
with an init call added in.

Cheers,
Jordan

On Fri, Nov 9, 2012 at 6:25 PM, Russell Keith-Magee  
wrote:




  On Fri, Nov 9, 2012 at 1:05 PM, Aaron Merriam  wrote:

Without setting request, args, and kwargs on on the view instance (which is 
done during the base dispatch view), anything in the view that assumes these 
values are present cannot run.   

Most of my views end up with functions which retrieve an object and then do 
some basic validation to ensure that a user has permissions, or that the object 
is valid in some fashion, or that some set of conditions is met prior to 
allowing any method call to happen.  

I have found that without this init method, the vast majority of my views 
end up re-writing dispatch which includes the super call.  This is especially 
annoying when you have to compare some aspect of the requesting user with an 
object that must be looked up with something from args or kwargs.  My view 
often already has this machinery built in, but it can't function without 
dispatch setting request, args, and kwargs, so to accomplish my check, I have 
to duplicate the lookup code in my dispatch method.

I don't propose mine is the best solution, but I know that it is 
non-intrusive, simple, and covers my use cases well.  It is also simple to 
accomplish any number of things since `init` merely needs to return a falsy 
value to allow the request to pass on through, raise an exception if that type 
of failure is desired, or return a response of it wants to hijack the view 
entirely.



  I'm starting to feel like I'm incredibly dense, because I still don't 
understand what your use case *is* - or, at least, why what your proposing 
provides any significant advantages over what you can do using basic Python 
inheritance techniques.

  Specifically, I still can't see why:

  class MyView(View):
  def  dispatch(self, request, *args, **kwargs):
  init()
  return super(MyView, self).dispatch(request, *args, **kwargs)

  def init():
  # your init logic here

  is superior to the solution provided by using basic Python inheritance:

  class MyView(View):
  def  dispatch(self, request, *args, **kwargs):
  # your init logic here
  return super(MyView, self).dispatch(request, *args, **kwargs)

  You have exactly the same workflow, and exactly the same order of operations. 
You don't need to document any special CBV-specific API -- e.g., when/how 
init() will be invoked, and with what assumptions about the request environment 
can be made -- and you don't have to incur the overhead of a function call (ok 
- the overhead is tiny, but let's not pretend it's zero).

  So - can someone explain to me what the advantage is? Why is this init() 
method needed?

  Yours,
  Russ Magee %-)

  -- 
  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 
mailto:django-developers%2bunsubscr...@googlegroups.com.
  For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.


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

Re: Trigger an event on add another

[Mark Lavin]

When I was working on a similar issue for django-selectable I created an 
issue to address this problem with a simple proof of concept patch 
https://code.djangoproject.com/ticket/15760. However I never followed 
through with the ticket to try to get something like this added. In the 
meantime another ticket was created and fixed which solves a large portion 
of the problem https://code.djangoproject.com/ticket/18241. With this 
change you can catch the click event of the add button. I still feel like 
the admin inline javascript is not particularly flexible and having some 
clearly documented hooks for this use case would be nice.

For what it's worth my solution in django-selectable was to patch the 
formset function to include my callback 
https://bitbucket.org/mlavin/django-selectable/src/efede3aa83ec6d372626eaac6f54c188287ec3d2/selectable/static/selectable/js/jquery.dj.selectable.js?at=default#cl-289
 Not 
the prettiest solution but it works.

Best,

Mark

On Friday, November 9, 2012 6:30:17 AM UTC-5, is_null wrote:
>
> Hi all,
>
> Is it possible to trigger an event on add-another ?
>
> Or is there a better solution to work around this problem ? 
> https://github.com/yourlabs/django-autocomplete-light/blob/master/autocomplete_light/static/autocomplete_light/widget.js#L267
>
> Thanks for answering
>
> Regards
>

-- 
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.google.com/d/msg/django-developers/-/zvzeX-CiNDgJ.
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: DatabaseError with empty IN clause with Paginator

[Chi Ho Kwok]

On Friday, 9 November 2012 00:31:39 UTC+1, Russell Keith-Magee wrote:

> If you can show a clear difference in behaviour between 1.3 and 1.4, then 
> you've definitely found a bug. If you can log this in Trac (and mark it as 
> a release blocker, since it's a change in behaviour), we can investigate 
> further.
>
> Yours,
> Russ Magee %-) 
>

I've traced the change back, but it doesn't seem to be introduced at 1.4. 
On 1.2, this works:

C:\Dev\django\bugs>manage.py shell
Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] 
on win32
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from bugtest.models import *
>>> crash()
[]
>>> import django
>>> django.VERSION
(1, 2, 0, 'final', 0)
>>>

On 1.3.4:

C:\Dev\django\bugs>manage.py shell
Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] 
on win32
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from bugtest.models import *
>>> crash()
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Dev\django\bugs\bugtest\models.py", line 16, in crash
print books
  File 
"C:\Dev\Python27\lib\site-packages\django-1.3.4-py2.7.egg\django\db\models\query.py",
 
line 69, in __repr__
data = list(self[:REPR_OUTPUT_SIZE + 1])
  File 
"C:\Dev\Python27\lib\site-packages\django-1.3.4-py2.7.egg\django\db\models\query.py",
 
line 84, in __len__
self._result_cache.extend(self._iter)
  File 
"C:\Dev\Python27\lib\site-packages\django-1.3.4-py2.7.egg\django\db\models\query.py",
 
line 273, in iterator
for row in compiler.results_iter():
  File 
"C:\Dev\Python27\lib\site-packages\django-1.3.4-py2.7.egg\django\db\models\sql\compiler.py",
 
line 680, in results
_iter
for rows in self.execute_sql(MULTI):
  File 
"C:\Dev\Python27\lib\site-packages\django-1.3.4-py2.7.egg\django\db\models\sql\compiler.py",
 
line 735, in execute
_sql
cursor.execute(sql, params)
  File 
"C:\Dev\Python27\lib\site-packages\django-1.3.4-py2.7.egg\django\db\backends\util.py",
 
line 34, in execute
return self.cursor.execute(sql, params)
  File 
"C:\Dev\Python27\lib\site-packages\django-1.3.4-py2.7.egg\django\db\backends\postgresql_psycopg2\base.py",
 
line 4
4, in execute
return self.cursor.execute(query, args)
DatabaseError: syntax error at or near ")"
LINE 1: ...ugtest_book" WHERE "bugtest_book"."author_id" IN () LIMIT 21
 ^
>>> import django; django.VERSION
(1, 3, 4, 'final', 0) 


It's also database dependent, I couldn't reproduce the issue with SQLite.


I've created a ticket, https://code.djangoproject.com/ticket/19263, but 
I've no idea how to classify it.

Thanks in advance for looking at this,


Chi Ho Kwok

-- 
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.google.com/d/msg/django-developers/-/gG9861FKpv0J.
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.

Trigger an event on add another

[James Pic]

Hi all,

Is it possible to trigger an event on add-another ?

Or is there a better solution to work around this problem ?
https://github.com/yourlabs/django-autocomplete-light/blob/master/autocomplete_light/static/autocomplete_light/widget.js#L267

Thanks for answering

Regards

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