Re: Is there a plan for Django to handle NoSQL databases natively?

[Trevor Joynson]

I've had good experiences using mongoengine with django.  It's not django's
ORM but it's very similar to it.
On Mar 26, 2013 12:36 PM, "Donnie Darko"  wrote:

> I really like Django. I've fiddled around a bit with Rails, but I
> personally prefer Django's logic. I also prefer Python over Ruby. Again,
> personal preferences. Despite all that, I am now switching back to Rails
> because of Django's lack of native support for databases like mongodb. I
> saw there was no plan for Django 1.5 to support NoSQL databases.
>
> I've tried to install django-nonrel as it looked promising, but with no
> success. Even if I succeeded, I can't trust this fork of django considering
> the lack of active development. There isn't even a post to tell you what
> version of the dependencies to install, some of which are updating quite
> fast. So you run into errors that are not well-documented, and it's just an
> horror.
>
> Django could be a long term investement for me, so I was wondering if
> there there was a plan to change Django's ORM to support NoSQL databases?
>
> --
> 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 http://groups.google.com/group/django-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Auction app

[Evgeny Demchenko]

There's this one:
https://github.com/kaijutech/Django-Auction

i'm about to try it out. If it's not good I'll create one from scratch.

Will keep you posted :)

On Monday, February 2, 2009 2:10:01 AM UTC+8, Erik Allik wrote:
>
> Does anyone know of an app written for Django that implements a kind  
> of (simple) web-auction functionality suitable for, say, selling arts,  
> valuable old books, or just random items?
>
> Erik
>

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Using values_list and extra on same queryset

[Larry Martell]

On Tue, Mar 26, 2013 at 8:14 PM, Larry Martell  wrote:
> On Tue, Mar 26, 2013 at 4:51 PM, Larry Martell  
> wrote:
>> I have some existing code that calls values_list on a queryset. I need
>> to add something using extra to this queryset. If I call extra before
>> values_list the extra stuff is gone from the query after the
>> values_list. If I call extra after the call to values_list it seems to
>> have to effect - the extra stuff is not in the query. Is there some
>> way to use both values_list and extra on same queryset?
>
> I think I may have found a bug. I stepped though the code, and
> values_list() does want to respect any extras that may have been
> added. In django/db/models/query.py(962)_setup_query() it does:
>
> if not self.query.extra and not self.query.aggregates:
>
> And for my case that is returning false, but I do have extras:
>
> (Pdb) print not self.query.extra
> False
> (Pdb) print self.query.extra
> {'top-bottom': (u'top-bottom', [])}
>
>
> This does not seem correct to me. Am I missing something here (because
> I've been coding since 4:30am and it's 8pm now)?

Ignore my last message - I was seriously sleep deprive3d when I made
it. But my original question remains - how can I use values_list and
extra on same queryset?

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Using values_list and extra on same queryset

[Tom Evans]

On Wed, Mar 27, 2013 at 12:38 PM, Larry Martell  wrote:
> Ignore my last message - I was seriously sleep deprive3d when I made
> it. But my original question remains - how can I use values_list and
> extra on same queryset?

It just seems to WFM:

Foo.objects.all().extra(select={'wibble': '1'}).values_list('pk', 'wibble')
[(611L, 1L), (612L, 1L), (613L, 1L), (614L, 1L), (615L, 1L), (616L, 1L)]

Works fine on my 1.3 and 1.4 sites, I don't have a 1.5 site handy..

Cheers

Tom

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Navigation Bar

[Simon Shaw]

I am Django/Web newbie developer and I am looking for the correct way to 
add a navigation bar (hopefully the correct term) to my ticketing app such 
that the options "Admin", "Open New Ticket", "View New Ticket", 
"Dashboard", "Logout" will always appear at the top of the page and that 
the page where the user is currently located will be highlighted.  Ideally, 
for users that are not logged in as Admin I would prefer not to show the 
admin option, should this not be possible I would like the admin option to 
be grayed out.

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Using values_list and extra on same queryset

[Larry Martell]

On Wed, Mar 27, 2013 at 6:52 AM, Tom Evans  wrote:
> On Wed, Mar 27, 2013 at 12:38 PM, Larry Martell  
> wrote:
>> Ignore my last message - I was seriously sleep deprive3d when I made
>> it. But my original question remains - how can I use values_list and
>> extra on same queryset?
>
> It just seems to WFM:
>
> Foo.objects.all().extra(select={'wibble': '1'}).values_list('pk', 'wibble')
> [(611L, 1L), (612L, 1L), (613L, 1L), (614L, 1L), (615L, 1L), (616L, 1L)]
>
> Works fine on my 1.3 and 1.4 sites, I don't have a 1.5 site handy..

Here's a very simple example showing it's not working for me

(Pdb) CST.objects.all().extra(select={'ep': 1}).values_list('image_measurer_id')
[(86456L,), (86454L,), (86452L,), (86450L,), (86448L,), (86446L,),
(86444L,), (86442L,), (86440L,), (86438L,), (86436L,), (86434L,),
(86432L,), (86430L,), (86428L,), (86426L,), (86424L,), (86422L,),
(86420L,), (86418L,), '...(remaining elements truncated)...']

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Avoiding Sessions

[Venkatraman S]

So, if i am right, usage of sessions makes an extra call to the DB for
every view with login_required.

SELECT "auth_user"."id", "auth_user"."password", "auth_user"."last_login",
"auth_user"."is_superuser", "auth_user"."username",
"auth_user"."first_name", "auth_user"."last_name", "auth_user"."email",
"auth_user"."is_staff", "auth_user"."is_active", "auth_user"."date_joined"
FROM "auth_user" WHERE "auth_user"."id" = 3

..app\debug_toolbar\utils\tracking/db.py in execute(118)
  stacktrace = tidy_stacktrace(reversed(get_stack()))

I do not want to be finicky about this 'extra' DB call, but was wondering
if someone has used the cookie-based approach and has avoided sessions
altogether. I just wanted to understand the implications on security and
what i need to be aware of when using cookies in this way. Any experiences?

-Venkat
http://twitter.com/venkasub

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Using values_list and extra on same queryset

[Karen Tracey]

On Wed, Mar 27, 2013 at 9:19 AM, Larry Martell wrote:

> Here's a very simple example showing it's not working for me
>
> (Pdb) CST.objects.all().extra(select={'ep':
> 1}).values_list('image_measurer_id')
> [(86456L,), (86454L,), (86452L,), (86450L,), (86448L,), (86446L,),
> (86444L,), (86442L,), (86440L,), (86438L,), (86436L,), (86434L,),
> (86432L,), (86430L,), (86428L,), (86426L,), (86424L,), (86422L,),
> (86420L,), (86418L,), '...(remaining elements truncated)...']
>


You have not included the extra select column ep in your values_list call...

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Avoiding Sessions

[Shawn Milochik]

Use django-redis-sessions as a back end instead of the database.
On Mar 27, 2013 9:35 AM, "Venkatraman S"  wrote:

> So, if i am right, usage of sessions makes an extra call to the DB for
> every view with login_required.
>
> SELECT "auth_user"."id", "auth_user"."password", "auth_user"."last_login",
> "auth_user"."is_superuser", "auth_user"."username",
> "auth_user"."first_name", "auth_user"."last_name", "auth_user"."email",
> "auth_user"."is_staff", "auth_user"."is_active", "auth_user"."date_joined"
> FROM "auth_user" WHERE "auth_user"."id" = 3
>
> ..app\debug_toolbar\utils\tracking/db.py in execute(118)
>   stacktrace = tidy_stacktrace(reversed(get_stack()))
>
> I do not want to be finicky about this 'extra' DB call, but was wondering
> if someone has used the cookie-based approach and has avoided sessions
> altogether. I just wanted to understand the implications on security and
> what i need to be aware of when using cookies in this way. Any experiences?
>
> -Venkat
> http://twitter.com/venkasub
>
> --
> 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 http://groups.google.com/group/django-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Navigation Bar

[Shawn Milochik]

If you put these links in your base template it will appear on every page.

If you wrap some of those links with template if/endif syntax and
check request.user to see if they have permission, you can hide
individual links, change their CSS classes, or replace them with a
something else.

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Lost CSS & Javascript in Django Admin

[Tim Cook]

Thank you James and Branko.

Yes, it was the relevant part of the docs that, actually I had read,
but didn't understand at the time.
I appreciate your patience in pointing it out to me.

Cheers,
Tim

On Mon, Mar 25, 2013 at 6:57 PM, Branko Majic  wrote:
> On Mon, 25 Mar 2013 18:12:44 -0300
> Tim Cook  wrote:
>
>> The Apache error.log has these types of entries:
>> "GET /static/admin/css/base.css HTTP/1.1" 404
>> "GET /static/admin/css/dashboard.css HTTP/1.1" 404
>> "GET /static/admin/js/actions.js HTTP/1.1" 404
>
> Did you follow-through the "Serving the admin files" section of the
> modwsgi instructions? In case of development server, it will
> automagically take care of serving the static content for you. In case
> of production servers like Apache, you will have to take care of that
> yourself.
>
> So, you need to configure Apache to serve the static files at
> path /static/, from some directory, and fill-up this directory with
> all the necessary static files.
>
> The recommended way is to use the manage.py collectstatic command (at
> least from what I've seen, I'm a beginner myself).
>
> Best regards
>
> --
> Branko Majic
> Jabber: bra...@majic.rs
> Please use only Free formats when sending attachments to me.
>
> Бранко Мајић
> Џабер: bra...@majic.rs
> Молим вас да додатке шаљете искључиво у слободним форматима.



-- 

Timothy Cook, MSc   +55 21 94711995
MLHIM http://www.mlhim.org
Like Us on FB: https://www.facebook.com/mlhim2
Circle us on G+: http://goo.gl/44EV5
Google Scholar: http://goo.gl/MMZ1o
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Navigation Bar

[Venkatraman S]

On Wed, Mar 27, 2013 at 5:55 PM, Simon Shaw  wrote:

> I am Django/Web newbie developer and I am looking for the correct way to
> add a navigation bar (hopefully the correct term) to my ticketing app such
> that the options "Admin", "Open New Ticket", "View New Ticket",
> "Dashboard", "Logout" will always appear at the top of the page and that
> the page where the user is currently located will be highlighted.  Ideally,
> for users that are not logged in as Admin I would prefer not to show the
> admin option, should this not be possible I would like the admin option to
> be grayed out.
>


django-tabs

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is there a plan for Django to handle NoSQL databases natively?

[Tim Cook]

I am not using it right now, but plan to when I have more Django
experience. So I have been watching the non-rel group:
 django-non-relatio...@googlegroups.com
and it does seem to be active now.  Maybe you want to recheck and if
they are having project management issues you can help?

HTH,
Tim

On Tue, Mar 26, 2013 at 1:10 PM, Donnie Darko  wrote:
> I really like Django. I've fiddled around a bit with Rails, but I personally
> prefer Django's logic. I also prefer Python over Ruby. Again, personal
> preferences. Despite all that, I am now switching back to Rails because of
> Django's lack of native support for databases like mongodb. I saw there was
> no plan for Django 1.5 to support NoSQL databases.
>
> I've tried to install django-nonrel as it looked promising, but with no
> success. Even if I succeeded, I can't trust this fork of django considering
> the lack of active development. There isn't even a post to tell you what
> version of the dependencies to install, some of which are updating quite
> fast. So you run into errors that are not well-documented, and it's just an
> horror.
>
> Django could be a long term investement for me, so I was wondering if there
> there was a plan to change Django's ORM to support NoSQL databases?
>
> --
> 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 http://groups.google.com/group/django-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



-- 

Timothy Cook, MSc   +55 21 94711995
MLHIM http://www.mlhim.org
Like Us on FB: https://www.facebook.com/mlhim2
Circle us on G+: http://goo.gl/44EV5
Google Scholar: http://goo.gl/MMZ1o
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Avoiding Sessions

[Venkatraman S]

Well, the intention of asking that Q was not to check any possible
data-store alternatives but to understand the nuances of the cookie based
approach. Am not a great security expert when it comes to cookies and the
limitations that it 'can' cause down the lane - and hence.

On Wed, Mar 27, 2013 at 7:28 PM, Shawn Milochik  wrote:

> Use django-redis-sessions as a back end instead of the database.
> On Mar 27, 2013 9:35 AM, "Venkatraman S"  wrote:
>
>> So, if i am right, usage of sessions makes an extra call to the DB for
>> every view with login_required.
>>
>> SELECT "auth_user"."id", "auth_user"."password",
>> "auth_user"."last_login", "auth_user"."is_superuser",
>> "auth_user"."username", "auth_user"."first_name", "auth_user"."last_name",
>> "auth_user"."email", "auth_user"."is_staff", "auth_user"."is_active",
>> "auth_user"."date_joined" FROM "auth_user" WHERE "auth_user"."id" = 3
>>
>> ..app\debug_toolbar\utils\tracking/db.py in execute(118)
>>   stacktrace = tidy_stacktrace(reversed(get_stack()))
>>
>> I do not want to be finicky about this 'extra' DB call, but was wondering
>> if someone has used the cookie-based approach and has avoided sessions
>> altogether. I just wanted to understand the implications on security and
>> what i need to be aware of when using cookies in this way. Any experiences?
>>
>> -Venkat
>> http://twitter.com/venkasub
>>
>> --
>> 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 http://groups.google.com/group/django-users?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>  --
> 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 http://groups.google.com/group/django-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django payment gateway with subscription management

[Venkatraman S]

And any other options other than that .. to be used Internationally?

I know of ... chargify, ccavenue, spreedly, fusebill, merchee,
cheddargetter, chargify, zuora etc. Am trying to do a comparison between
all these possible services in terms of their fees and also features.

On Wed, Mar 6, 2013 at 2:17 AM, Mayukh Mukherjee  wrote:

> Stripe if you're in the us (am not sure which other countries they've
> rolled out to).
>
>
> On Tue, Mar 5, 2013 at 3:34 PM, Jaimin Patel  wrote:
>
>> Hello,
>>
>> We are evaluating different payment gateways for subscription management
>> for one of the app which requires the subscription based model (monthly, 6
>> months, year).
>>
>> I checked different packages available here -
>> https://www.djangopackages.com/grids/g/payment-processing/
>>
>> Though I am confuse which one I should be using, can someone recommend
>> which one is actively maintained and most commonly used for subscription
>> based model where users can signup for free and if they want they can
>> subscribe later on. We don't required to store the credit card details and
>> it can be taken care by the payment gateway.
>>
>> Thanks.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-users+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-users@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-users?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>
>
> --
> Mayukh Mukherjee
> http://www.linkedin.com/in/mayukhmmukherjee
>
>
>  --
> 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 http://groups.google.com/group/django-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Avoiding Sessions

[Shawn Milochik]

Some clients may not allow cookies, which would be a problem if that's
your full session strategy. If you're storing nothing but the default
information in the cookie then there shouldn't be any risk, and in any
case the cookie is encrypted with the SECRET_KEY from your settings.
If you store additional information in the session then you run the
risk of exceeding the size allowed for a cookie, and theoretically
that information being exposed, although that's unlikely if your
SECRET_KEY is good.

In my opinion, using Redis as a back-end will be much better for
multiple reasons, not the least of which is performance. Also,
built-in key expiration in Redis is excellent (check your existing
session table for the entire history of sessions for your
application).

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is there a plan for Django to handle NoSQL databases natively?

[Shawn Milochik]

Another point is one made by Alex Gaynor at PyCon 2012. Too often,
people ask "How do I do X in Django," when they should be asking "How
do I do X in Python," or "Does Django have something for X."

The first question is too limiting. Remember that Django is just some
Python code.

The second question expands your thinking. Is there any Python library
out there that does what I want? If not, should I write one?

The third question is good because it may prevent you from
re-inventing the wheel. If Django *does* have something that does what
you want, you may as well use it. But if not, you're far from stuck.

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is there a plan for Django to handle NoSQL databases natively?

[Javier Guerra Giraldez]

On Tue, Mar 26, 2013 at 6:49 PM, Russell Keith-Magee
 wrote:
> On Wed, Mar 27, 2013 at 12:46 AM, Javier Guerra Giraldez
>  wrote:
>>
>> since there's no such thing as "common NoSQL features", each datastore
>> would need its own modifications, so i think the common attitude is
>> that most of these features don't belong in the ORM.
>
>
> I'm not sure where you've got that impression. Django's ORM was
> *specifically* designed in a way to allow for NoSQL backends. Look at the
> architecture of the django.db module -- there's a query module, and a sql
> submodule. There's very little SQL content in the base query module. That's
> so that we can add a "noSQL" module at some later date. We've also been
> aggressive about adding SQL-specific features (e.g., HAVING clauses, GROUP
> BY clauses) to the ORM API.

i didn't say (and i don't believe) that the ORM is tied to SQL.  it
certainly could use other kind of backends.

What i did say (and still think) that NoSQL is too broad to just be a
backend (like "the study of non-elephant animals").  I think the only
thing most of NoSQL datastores have in common is that you start most
queries with some sort of key; but once you get there, they all
diverge widely.


my advice (and slight experience) is that it's just Python, you can
use any datastore you wish.   Also, the loose-coupling of templates
means you can give them any record-like object instead of an ORM
record, and any sequence-like object instead of a queryset.

what you do lose is the ability to unwind related data objects from a
single record, or further filter the queryset, but:

a) most NoSQL stores don't care about relationships, and
b) some NoSQL stores can't handle record filtering


> There's a *very* clear high level API picture of how NoSQL integration to
> the ORM API would happen. See the design discussions around the NoSQL GSoC
> project for more details.

AFAIR, there were two sides:

A) focus on common features

B) emulate some features on backends that don't provide them

my position is that the A solution quickly becomes an empty set, so i
a way, it's already done!  The B option is interesting but the
performance/scalabilty profiles of each feature is completely
different on different backends, so it could be misleading to wrap on
the same API.


Still, i do like the "quack this way" observation.  Just by
formalizing some defined protocols for the most useful features, we
get a big boost in aplicability.

some easy to convene suggestions:

- make collections iterable as python sequences.  bonus points if you
handle [start:end] slices

- if you handle filtering in a collection, use the
.filter(condition=value, cond2=val2) style on the collection object

- if you handle relationships, expose them as attributes on a "record"
object.  these could be records or collections.



> What we *don't* have is a huge amount of interest in actually doing the work
> to make NoSQL a development priority. NoSQL generated a lot of buzz a few
> years ago, but now the buzz has died down, sober heads have prevailed, and
> it's become clear that a well configured PostgreSQL store is easily a match
> for a NoSQL for most use cases.

wholeheartedly agree


-- 
Javier

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Avoiding Sessions

[Tom Evans]

On Wed, Mar 27, 2013 at 1:35 PM, Venkatraman S  wrote:
> So, if i am right, usage of sessions makes an extra call to the DB for every
> view with login_required.
>
> SELECT "auth_user"."id", "auth_user"."password", "auth_user"."last_login",
> "auth_user"."is_superuser", "auth_user"."username",
> "auth_user"."first_name", "auth_user"."last_name", "auth_user"."email",
> "auth_user"."is_staff", "auth_user"."is_active", "auth_user"."date_joined"
> FROM "auth_user" WHERE "auth_user"."id" = 3
>
> ..app\debug_toolbar\utils\tracking/db.py in execute(118)
>   stacktrace = tidy_stacktrace(reversed(get_stack()))
>
> I do not want to be finicky about this 'extra' DB call, but was wondering if
> someone has used the cookie-based approach and has avoided sessions
> altogether. I just wanted to understand the implications on security and
> what i need to be aware of when using cookies in this way. Any experiences?
>
> -Venkat
> http://twitter.com/venkasub
>

This query has mostly nothing to do with sessions. This query occurs
when the authentication middleware populates request.user for logged
in users. The only thing that comes from the session is the user id
and the auth backend that authorized them, which is persisted in there
at login.

The cookie based approach does not avoid sessions, it inserts the
session data into a cookie and makes it tamper proof. If using the
cookie based session, the query above would still happen at exactly
the same point in the request.

Using the cookie based session backend would only avoid a SELECT query
at the start of the request to populate the session, and a UPDATE
query at the end of the request iff the data was modified.

The downsides of using cookie based sessions is that you are limited
to how much content you can place in there, and the session contents
are visible (but not modifiable) by the user. You lose control over
storage of the session, meaning you cannot change things in the
session (or even delete it) without the user presenting themselves at
your website.

Most of these are documented in the docs for cookie based sessions:

https://docs.djangoproject.com/en/1.5/topics/http/sessions/#using-cookie-based-sessions

Cheers

Tom

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Django 1.5 tutorial error: 'module' has no attribute 'StackedInLine'

[+Emmanuel]

Hello there,

I am working through the django tutorial at djangoproject.com. So far 
everything works out fine until Section 2.4.6 (customizing the admin form). 
Django throws an error:  *'module' has no attribute 'StackedInLine'. *I 
checked around and this seems to work:
*if you use import to include a module, make sure you don’t have a file 
named just the same as the module you are trying to include in current 
directory. It seems python takes preference for local files over modules 
thus import fails.*
Problem is, how now do I call the Poll admin module if it's name has been 
changed to say admin2.py since naming it admin.py conflicts with the main 
django admin.
I hope this makes sense!
Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Navigation Bar

[Andre Terra]

In my last project I created a template tag that would take an app name as
an argument and build the links according to that user's permissions for
the links in that app. This made the template easier to read at the cost of
having to write the function and learning how it worked. Since I was the
only one in the project, I didn't have to worry too much about that, so it
was just a matter of using {% menu 'profiles' %} and {% menu 'blog' %}, for
example.

I don't know if this is design pattern is The Right Way (TM), but It Just
Works (TM).

You can find documentation on writing custom tags here:
https://docs.djangoproject.com/en/dev/howto/custom-template-tags/


Cheers,
AT

On Wed, Mar 27, 2013 at 11:16 AM, Venkatraman S  wrote:

>
> On Wed, Mar 27, 2013 at 5:55 PM, Simon Shaw wrote:
>
>> I am Django/Web newbie developer and I am looking for the correct way to
>> add a navigation bar (hopefully the correct term) to my ticketing app such
>> that the options "Admin", "Open New Ticket", "View New Ticket",
>> "Dashboard", "Logout" will always appear at the top of the page and that
>> the page where the user is currently located will be highlighted.  Ideally,
>> for users that are not logged in as Admin I would prefer not to show the
>> admin option, should this not be possible I would like the admin option to
>> be grayed out.
>>
>
>
> django-tabs
>
>  --
> 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 http://groups.google.com/group/django-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django 1.5 tutorial error: 'module' has no attribute 'StackedInLine'

[Tom Evans]

On Wed, Mar 27, 2013 at 3:32 PM, +Emmanuel  wrote:
> Hello there,
>
> I am working through the django tutorial at djangoproject.com. So far
> everything works out fine until Section 2.4.6 (customizing the admin form).
> Django throws an error:  'module' has no attribute 'StackedInLine'. I
> checked around and this seems to work:
> if you use import to include a module, make sure you don’t have a file named
> just the same as the module you are trying to include in current directory.
> It seems python takes preference for local files over modules thus import
> fails.

Mmmm, yes, but this is not what is happening. If you have this structure:

polls
├── __init__.py
├── admin.py
├── models.py
└── views.py

and in the admin.py write "from django.contrib import admin", it will
not get confused about the "admin.py" in the same directory. If you
had a file called "django.py", then that would confuse the importing.

> Problem is, how now do I call the Poll admin module if it's name has been
> changed to say admin2.py since naming it admin.py conflicts with the main
> django admin.

The admin file in your poll app must be called admin.py, else it will
not be discovered.

The easiest way to work out why you are getting this error, would be
to give us the complete error message - there should be multiple lines
-  and the contents of your admin.py.

Cheers

Tom

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django 1.5 tutorial error: 'module' has no attribute 'StackedInLine'

[Karen Tracey]

On Wed, Mar 27, 2013 at 11:32 AM, +Emmanuel  wrote:

> Hello there,
>
> I am working through the django tutorial at djangoproject.com. So far
> everything works out fine until Section 2.4.6 (customizing the admin form).
> Django throws an error:  *'module' has no attribute 'StackedInLine'. *
>

Right, the L in StackedInLine should NOT be capitalized, it should be just
an initial capital letter on Inline: StackedInline

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Getting an AttributeError while creating a Django project

[Olga Zasenko]

Hi, everybody!
I'm following the instructions on website docs.djangoproject.com and trying 
to create my very first Django project.
The only result I get is a confusing error:

AttributeError: 'module' object has no attribute '_handlerList'.

My Django version is 1.5, Python - 2.7.3.
I completely deleted and reinstalled Django, but it didn't help.
Maybe the attached screenshot will help.

Thank you.

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


<>

Re: Getting an AttributeError while creating a Django project

[Tom Evans]

On Wed, Mar 27, 2013 at 4:39 PM, Olga Zasenko  wrote:
> Hi, everybody!
> I'm following the instructions on website docs.djangoproject.com and trying
> to create my very first Django project.
> The only result I get is a confusing error:
>
> AttributeError: 'module' object has no attribute '_handlerList'.
>
> My Django version is 1.5, Python - 2.7.3.
> I completely deleted and reinstalled Django, but it didn't help.
> Maybe the attached screenshot will help.
>
> Thank you.
>

I expect that the django-admin.py you are running is not the one you
have just installed. Check your PATH and see which is being run.

Cheers

Tom

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

manytomany field and intermediary table from a legacy database

[Vittorio]

I know that when I define a manytomany field automagically "behind the scene 
Django creates an intermediary join table to represent the many-to-many 
relationship".
Now I have a legacy MySQL db, feeded by an existing procedure built in 
Filemaker  via ODBC, which I would like to use with django too. In this legacy 
db the "intermediary join table" already exists but with a different name and 
with different name fields.
How can I tell Django to use that table without creating a new one?
An example would be very useful.
Bye from Rome
Vittorio

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Using values_list and extra on same queryset

[Larry Martell]

On Wed, Mar 27, 2013 at 7:38 AM, Karen Tracey  wrote:
>
> On Wed, Mar 27, 2013 at 9:19 AM, Larry Martell 
> wrote:
>>
>> Here's a very simple example showing it's not working for me
>>
>> (Pdb) CST.objects.all().extra(select={'ep':
>> 1}).values_list('image_measurer_id')
>> [(86456L,), (86454L,), (86452L,), (86450L,), (86448L,), (86446L,),
>> (86444L,), (86442L,), (86440L,), (86438L,), (86436L,), (86434L,),
>> (86432L,), (86430L,), (86428L,), (86426L,), (86424L,), (86422L,),
>> (86420L,), (86418L,), '...(remaining elements truncated)...']
>
>
>
> You have not included the extra select column ep in your values_list call...

Doh! Thanks much!

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is file based cache is safe for concurrent process?

[Russell Keith-Magee]

On Wed, Mar 27, 2013 at 8:57 AM, Ivan Smirnoff  wrote:

> Hi all.
> Can anyone tell, does django.cache locks file for writing by concurrent
> process?


Django's file-based cache doesn't do any locking. It wasn't really designed
as a production system -- it's more of a test that the cache API works as
an abstraction.

Yours,
Russ Magee %-)

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

South Error in migration:

[Tim Cook]

I can't find a similar scenario in the list archives, so .

I had run the initial migration, etc and all seemed fine.

I modified one model from this:
class CCD(models.Model):
rm_version = models.ForeignKey(RMversion, related_name='%(class)s_related+')
...

to this:
class CCD(models.Model):
prj_name = models.ForeignKey(Project, verbose_name="Project Name")
...

The new ForeignKey in CCD, points to this, which already has the
RMversion relation.

class Project(models.Model):
prj_name = models.CharField("project name", max_length=110, unique=True)
rm_version = models.ForeignKey(RMversion, related_name='%(class)s_related+')
owner_group = models.CharField(max_length=110) #must be a member
of this group to edit this project

During the migration, here are the prompts and my responses:

(django)tim@tim-us_12-04:~/webapp/apps/mlhim$ python manage.py
schemamigration ccdgen --auto
 ? The field 'CCD.rm_version' does not have a default specified, yet
is NOT NULL.
 ? Since you are removing this field, you MUST specify a default
 ? value to use for existing rows. Would you like to:
 ?  1. Quit now, and add a default to the field in models.py
 ?  2. Specify a one-off value to use for existing columns now
 ?  3. Disable the backwards migration by raising an exception.
 ? Please select a choice: 2
 ? Please enter Python code for your one-off default value.
 ? The datetime module is available, so you can do e.g. datetime.date.today()
 >>> See Project Value
 ! Invalid input: invalid syntax (, line 1)
 >>> "See Project RM"
 - Deleted field rm_version on ccdgen.CCD
 ? The field 'CCD.prj_name' does not have a default specified, yet is NOT NULL.
 ? Since you are adding this field, you MUST specify a default
 ? value to use for existing rows. Would you like to:
 ?  1. Quit now, and add a default to the field in models.py
 ?  2. Specify a one-off value to use for existing columns now
 ? Please select a choice: 2
 ? Please enter Python code for your one-off default value.
 ? The datetime module is available, so you can do e.g. datetime.date.today()
 >>> "2.4.2"
 + Added field prj_name on ccdgen.CCD
Created 0002_auto__del_field_ccd_rm_version__add_field_ccd_prj_name.py.
You can now apply this migration with: ./manage.py migrate ccdgen
(django)tim@tim-us_12-04:~/webapp/apps/mlhim$ python manage.py migrate ccdgen
Running migrations for ccdgen:
 - Migrating forwards to
0002_auto__del_field_ccd_rm_version__add_field_ccd_prj_name.
 > ccdgen:0001_initial
FATAL ERROR - The following SQL query failed: CREATE TABLE
"ccdgen_rmversion" ("id" serial NOT NULL PRIMARY KEY, "version_id"
varchar(10) NOT NULL UNIQUE);
The error was: relation "ccdgen_rmversion" already exists

Error in migration: ccdgen:0001_initial
DatabaseError: relation "ccdgen_rmversion" already exists


So, I have this "already exists" error.

Any hints on how to fix this?

Here is what is installed:
Django==1.5
South==0.7.6
Unipath==0.2.1
argparse==1.2.1
distribute==0.6.24
django-extensions==1.1.1
docutils==0.10
psycopg2==2.4.6
six==1.2.0
wsgiref==0.1.2

Using Postgres-9.1 on Unbuntu 12.04LTS


As always, THANKS!!!

--Tim



-- 

Timothy Cook, MSc   +55 21 94711995
MLHIM http://www.mlhim.org
Like Us on FB: https://www.facebook.com/mlhim2
Circle us on G+: http://goo.gl/44EV5
Google Scholar: http://goo.gl/MMZ1o
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

No multiple calls while iterating the queryset in template

[Venkatraman S]

Interesting Observation: So, am passing a queryset to my template and based
on the way a field in the record 'starts-with', i am rendering the record
into different 'tables' in the view.

Something like:

{% for record in settings %}
 {%if record.type|starts_with:"EMAIL_" %}
 ...show record details .. 
 {% endif %}
{% endfor %}


{% for record in settings %}
 {%if record.type|starts_with:"WORKSPACE_" %}
 ...show record details .. 
 {% endif %}
{% endfor %}


{% for record in settings %}
 {%if record.type|starts_with:"DASHBOARD_" %}
 ...show record details .. 
 {% endif %}
{% endfor %}

I was worried that passing over the queryset in different regions in the
'same' template might cause multiple(in this case 3) different queries to
the DB. But DDT shows me just one query to the DB :)

Regards,
Venkat
@venkasub

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: South Error in migration:

[Juan Pablo Martínez]

do 0001 --fake, your table south_migrations dont have the row indicating
that initial


On Wed, Mar 27, 2013 at 8:49 PM, Tim Cook  wrote:

> I modified one model from this:





-- 
juanpex

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

RE: No multiple calls while iterating the queryset in template

[Babatunde Akinyanmi]

Yeah, that's expected behavior.

settings = SomeModel.objects.all()
for e in settings:
print e.pk
for e in settings:
print e.pk
for e in settings:
print e.pk

In the above, the database will be hit only once but..

for e in SomeModel.objects.all():
print e.pk
for e in SomeModel.objects.all():
print e.pk
for e in SomeModel.objects.all():
print e.pk

the database will be hit three times

Sent from my Windows Phone
--
From: Venkatraman S
Sent: 3/28/2013 3:51 AM
To: django-users@googlegroups.com
Subject: No multiple calls while iterating the queryset in template

Interesting Observation: So, am passing a queryset to my template and based
on the way a field in the record 'starts-with', i am rendering the record
into different 'tables' in the view.

Something like:

{% for record in settings %}
 {%if record.type|starts_with:"EMAIL_" %}
 ...show record details .. 
 {% endif %}
{% endfor %}


{% for record in settings %}
 {%if record.type|starts_with:"WORKSPACE_" %}
 ...show record details .. 
 {% endif %}
{% endfor %}


{% for record in settings %}
 {%if record.type|starts_with:"DASHBOARD_" %}
 ...show record details .. 
 {% endif %}
{% endfor %}

I was worried that passing over the queryset in different regions in the
'same' template might cause multiple(in this case 3) different queries to
the DB. But DDT shows me just one query to the DB :)

Regards,
Venkat
@venkasub

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Testing with a custom user model as a ForeignKey in Django 1.5

[Felipe Coelho]

2013/3/18 Felipe Coelho 

>  1) Using tests that need the models, but don't actually touch the
>> database. This means you can put the model definition inline in the test
>> code, so AUTH_USER_MODEL has the right value when the code is run. This
>> lets us test validation conditions, etc, but not hit the database. You
>> *might* be able to get away with manually running syncdb in the middle of
>> the test -- Django's swappable_model test contains an example of doing
>> this, but only for the purposes of recreating permissions, not tables.
>
>
> The issue is that I'm trying to port an application with a whole test
> suite to work with custom user models, so I've got many tests which make
> use of classes like ModelWithForeign already.
>
>
>>  2) Define 2 "ModelWIthForeign" classes, and use the "right" one
>> depending on what the User model is at the time of test. This works fine
>> for Django's purposes because "ModelWithForeign" is a test-only model, so
>> it doesn't matter if you have a few of them. This approach won't be
>> successful if you're actually shipping ModelWithForeign as a core part of
>> your system.
>>
>>  3) Use test decorators to skip the test if a non-default user model is
>> in use.
>>
>
> The issue really is that I'm using ModelWithForeign in here, but the real
> app has one class with a ForeignKey to the user model as well. I can
> certainly skip the tests which use that model or which touch the database,
> but since this is a user registration app, being able to test it with other
> user types is quite a requirement for me.
>
>
>> Any suggestions on how to improve Django's testing infrastructure to
>> handle custom User models would be gratefully accepted (especially if they
>> come with patches). It's still new code, so reports of problems like yours
>> are helpful in shaping what features we've missed during initial
>> development.
>>
>
> I don't have any knowledge on the inside of Django, but if I figure out
> something, I'll certainly share it and try to create a patch for it.
>
> Currently I'm running the test suite using a runtests.py file like this
> one , and I'm thinking of
> two possible "solutions":
>
>- Making the runtests.py configure the system with different
>AUTH_USER_MODEL values each time, in a way that would run the tests
>multiple times, each time with a different database layout. The test suite
>would be in charge of creating the database each time, but since I can't
>call settings.configure multiple times, I somehow have to "unload" it
>before moving on to the next test group. This also has the disadvantage
>that, if built into my runtests.py, running the test suite when the app is
>installed in a larger project, only the tests running on the
>project-specified value for AUTH_USER_MODEL would run.
>- Maybe I could use multiple databases. In each one, the ForeignKey
>would be attached to a different user model, and then different databases
>could be selected depending on the currently defined user model. I don't
>know if that is possible, though.
>
> Hi, just a follow up. I had this on StackOverflow as well but didn't get
any answers there, so I just posted the method I'm currently using.
Essentially, I'm launching a different process for each user model, in a
way that I don't have to deal with user model changes, I just accept them
as they are and continue testing. More details:
http://stackoverflow.com/questions/15369987/testing-with-a-custom-user-model-as-a-foreignkey-in-django-1-5/15675119#15675119

-- 
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 http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.