Melb Django School Second GO

Hey Guys,

Melb Django & Common Code is starting its second round of free classes on Django. The classes are going to be held fortnightly starting March 12 from 4-6pm. They will be going through the essentials of Django to advance topics. The course will be given by leading Django Developers in the industry. Please bring a laptop and we'll provide the rest. See you in School!

If you have any questions please contact melbdjangoschool@acommoncreative.com.

Cheers,

Darren

--
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+unsubscribe@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.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/b39acf36-3a9f-411d-8aff-a172c8bfa754%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Problem installing and using smart_selects

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJU88RnAAoJEC0ft5FqUuEhTucQALsg0YsmG+Mmu94wCbCONSUK
dxneVLQJRqZ+dDuaIVmCJ9qMbpzbGVrFGjfUMoCmjzQvpM8+OqDriHapMz8gjEuR
swW9NZeYNfSmCh1fHKhTeWpVyfiHfyX1X1IUMbZFo10O6JHoHcX02C1PGBS3IZ5w
q/WABuQBZLLYcWAQWvgHU4S1KvnA8gauGAMmDgE1bWd6zCZWIeqeIBP06kdDrwJ2
cOpnP8yr6DDCjV/r7ztyWA5ez8zQHRv/GwZfsFs0FLW0Kn08rfKBpG4fy7JjPsR/
PF1Q84EcsaLFxhKxXjqUEUnlCsCHnqalIqXWgS+rDVGCnvb6yoqCFYHk475E9msl
jKIIIsBIeg0xq34fbnP0zItrkjjoT3nOMt4vTeVfVj8ZaSy1U4m7EkRHEehdL35P
hTLgxBg/o57w33JjpN6KYc9k8dmGLqKYogrpYRlbPQIAK87rb7mgEfUxmaD4yGiM
eqWMKjmDpoSYp9olUvZz2zOBQrZXAjk+uV/KbfkiNI2vzGosJE/khvEJaCqlMS40
kBYLecMCmFNZztHXVHYc787p4NwR4qLOmKZ4idm+/+4wibftTwARQYUn5CMBrNZy
PgCTaL2f8NKdjZYzYhwNuNsYjnteDZwOXnxIUsMlwuNb+UpH6WZCVh+KW7U8nIPH
BK/TRkuCkq3De6ZjUFwi
=ZjW7
-----END PGP SIGNATURE-----
Hi Michael,

On 03/01/2015 01:11 AM, Michael Ackary wrote:
> Smart Selects looked so simple and promising for chained selects
> (https://github.com/digi604/django-smart-selects). However, no matter
> how I install it, it doesn't seem to work. Here is what I've tried:
>
>
> *Attempt #1 - putting it in django.contrib
> *
> Copied the smart_selects folder to /django/contrib/smart_selects
>
> Added "django.contrib.smart_selects" to INSTALLED_APPS in settings.py
>
> But within Django shell I got this error:
>
>>>> from django.contrib import smart_selects
>>>> smart_selects.urls
> AttributeError: 'module' object has no attribute 'urls'

You don't ever want to do this. The "django.contrib" module is for
modules distributed with Django; it's not a place to add your own
additional code.

It also doesn't work, because smart_select expects to be able to import
itself as "smart_select", not as "django.contrib.smart_select."

> *Attempt #2 - installed using pip
> *
> I removed the smart_selects folder from /django/contrib folder (above)
> and then installed using pip... which put smart_selects in the Python
> site-packages folder.
>
> But then trying to use smart_selects within urls.py produced an ugly
> "ImportError: cannot import name simplejson" which suggests
> smart_selects has some outdated dependencies. (I"m using Django 1.7).

This is the right way to make use of third-party code. The problem here,
as you say, is just that smart_select has some outdated code. It's
actually been fixed in master, just not posted to PyPI yet, so you'll
need to install it directly from git, as mentioned in the fourth comment
here: https://github.com/digi604/django-smart-selects/issues/70

> *Attemp #3 - putting smart_packages in the root folder of my Django project
> *
> When smart_selects is placed here, again I can import smart_selects from
> the Django shell but not access smart-selects.urls :
>
> Type "help", "copyright", "credits" or "license" for more information.
> (InteractiveConsole)
>>>> import smart_selects
>>>> dir(smart_selects)
> ['__builtins__', '__doc__', '__file__', '__name__', '__package__',
> '__path__', 'models']
>>>> smart_selects.urls
> Traceback (most recent call last):
> File "<console>", line 1, in <module>
> AttributeError: 'module' object has no attribute 'urls'
>
>
> Finally it works if i do this:
>
>>>> import smart_selects.urls
>>>> smart_selects.urls
> <module 'smart_selects.urls' from
> '/Users/chas/Projects/switch/djangoroot/smart_selects/urls.pyc'>

The difference between the "doesn't work" and "works" versions here
doesn't have anything to do with how you've installed the code, it's
simply how submodule imports work in Python. Submodules are never
automatically imported unless you import them explicitly.

> However, I really don't like putting apps here since they clutter up my
> own development (and would rather keep 3rd party apps in django/contrib).

Yes, this installation technique will work fine, but it clutters things
up and makes it harder to upgrade in the future.

Carl

--
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+unsubscribe@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.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/54F3C467.7080203%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Re: Different between Object-save and form-save

Something like that. The essence of "form_save" is to save data from a form to the fields of the User model in the database. The thing to note is that a Form's save method returns the object that was saved. Also, a Form's save method and model save method do the same thing

On 1 Mar 2015 20:30, "ADEWALE ADISA" <solixzsystem@gmail.com> wrote:

OK, thanks for the response. So the essence of the form_save() is to get the user object in which the password property can be set properly.
Thanks alot

On Mar 1, 2015 6:38 PM, "Vijay Khemlani" <vkhemlan@gmail.com> wrote:

Both save the user to the database, but "user_form.save()" leaves the user password in plain text (which won't work when the user tries to login later) so the password must be set correctly (user.set_password(user.password)) and then the user has to be saved again for the correct (hashed) password to be stored.

On Sun, Mar 1, 2015 at 12:57 PM, ADEWALE ADISA <solixzsystem@gmail.com> wrote:

Hi guys, pls help with little explanation on the extract below from tango tutorial. In the code, they call user_form().save() to save into database. Then latter call user.save(). Pls what's the different between the two ? Where did user.save() save to ?

from rango.forms import UserForm, UserProfileForm

def register(request):

    # A boolean value for telling the template whether the registration was successful.
    # Set to False initially. Code changes value to True when registration succeeds.
    registered = False

    # If it's a HTTP POST, we're interested in processing form data.
    if request.method == 'POST':
        # Attempt to grab information from the raw form information.
        # Note that we make use of both UserForm and UserProfileForm.
        user_form = UserForm(data=request.POST)
        profile_form = UserProfileForm(data=request.POST)

        # If the two forms are valid...
        if user_form.is_valid() and profile_form.is_valid():
            # Save the user's form data to the database.
            user = user_form.save()

            # Now we hash the password with the set_password method.
            # Once hashed, we can update the user object.
            user.set_password(user.password)
            user.save()

            # Now sort out the UserProfile instance.
            # Since we need to set the user attribute ourselves, we set commit=False.
            # This delays saving the model until we're ready to avoid integrity problems.
            profile = profile_form.save(commit=False)
            profile.user = user

--
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+unsubscribe@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.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAMGzuy_saD%3DscV_CJtKzcss2siPktvFxi1oCUD-BvCEURtA5jg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@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.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CALn3ei34SRTYAxP4oaSExM2Nt-tjym4PXP2q2xuSgkkH8TV_UA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@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.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAMGzuy8aX8ehs4Qd2RgkueERA-OmDQg8gbE%3DVxJCB8heKw%2B03A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@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.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2BWjgXOuT8K1epLwU3ds3dL_UNDHrkhQtwQk34sqm2MsOSMm8g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can the new `Prefetch` solve my problem?

Ask and you shall receive (eventually). Another post in this list has an example using Prefetch(), perhaps that will help you:

https://groups.google.com/d/msgid/django-users/3daddb38-3260-4f7d-9559-7d0d3f17b59e%40googlegroups.com?utm_medium=email&utm_source=footer

On Feb 27, 2015 2:38 AM, "James Schneider" <jrschneider83@gmail.com> wrote:

On Feb 27, 2015 12:51 AM, "aRkadeFR" <contact@arkade.info> wrote:
>
> Yeah, but from my experience, your example through a new
> query. You have to (and please correct me if I'm wrong or
> there are other ways) use the self.chair_set.all() in order
> to not through a new query when you have prefetched the
> chairs.

AFAIK, self.chair_set.all() would always spawn a second query unless something like select_related() had been used previously to cache that query result

I provided several examples, some of which spawn a second query (and may be appropriate, I can't provide an affirmative answer for the OP without knowing how many queries are being run per page load and average query time, etc.). You'll need to be more specific.

I think I accidentally referred to some of the model fields as if they were FK's, but they probably should have had .all() after all of the references since everything was an M2M relationship.

>
> To be simple and answer the problem: my only solution I
> have in mind is to prefetched all the objects (chairs), and
> then filter it in python with properties like I said. But as you
> said it will load too much objects...

I think there was some miscommunication here. The OP stated that loading all of the chairs was infeasible, and I would tend to agree.

My only clarification would be that loading all of the chairs via something like Chair.objects.all() would be a bad idea, since you have no idea how many chairs you may have in the entire database.

Loading >10k Chair objects into memory and having Django coerce those into model objects, and then performing post processing in some custom app code to filter that list back down to something reasonable will give you a bad time, every time. Your users will be unhappy with pages that take seconds to load, and your server processes will be unhappy assuming you have plenty of RAM/CPU to handle such a request. Now multiply that load by X number of users...and you're quickly hitting CPU and process limits for RAM allocation.

However, "loading all of the chairs" via a M2M or FK relationship such as desk_obj.nearby_chairs.all() (assuming the OP reconfigured the model fields as I suggested before, or even using the existing Chair M2M to Desk) would likely be perfectly valid and would probably be a small subset of the total chairs in the system (or maybe None or all of them).

>
> Still watching the thread cause I have couple of problems
> like this one :)
>

I don't necessarily run in to this specific problem, so I'm not sure how much more I can contribute. A lot of the model changes I suggested were educated guesses and may not be valid at all given other requirements or design considerations in the project.

> aRkadeFR
>
>
> On 02/26/2015 08:27 PM, James Schneider wrote:
>>
>> Heh, I just realized that aRkadeFR had replied with a similar idea to use a property. At least I know I'm not too far off on my thinking. :-D
>>
>> -James
>>
>> On Thu, Feb 26, 2015 at 11:02 AM, James Schneider <jrschneider83@gmail.com> wrote:
>>>
>>> Whoops, accidentally sent that last one too early, here's the continuation:
>>>
>>> However, that probably doesn't buy you much since you are still doing an extra query for every Desk you pull from your original query.
>>>
>>> Funny enough, I was googling around for an answer here, and stumbled across this:
>>>
>>> https://docs.djangoproject.com/en/1.7/ref/models/queries/#django.db.models.Prefetch
>>>
>>> which I think is what you were referring to initially in your OP. I wasn't even aware of its existence. Prefetch() is a helper class for prefetch_related(). Taking a quick glance through the source code, I would imagine that it probably won't help you much, since the functionality of that class only controls the action of prefetch_related().
>>>
>>>
>>> Zooming out a bit, the crux of your problem is this: An attribute you wish to populate is not an FK or M2M field, it is an entirely separate Queryset with some moderately complex filters. The built-in ORM functionality for pre-loading via prefetch/select_related() is expecting a FK or M2M relationship and can't  use another queryset AFAIK. The high-level functionality of prefetch_related() is probably close to what you want, which is to run a single second query to collect all of the favorite_or_nearby_chairs for all of the Desks in your original query, and then glue everything together behind the scenes in Python to make the desk_obj.favorite_or_nearby_chairs available seamlessly.
>>>
>>> I would then wonder if there is another way to organize this data to make it easier to work with? How about adding a 'favorite_chairs' field to the Desk model that has an M2M to Chair? I would also update your 'nearby_desks' model field to use 'nearby_chairs' as the related_field. 
>>>
>>> Then you could do something like the following:
>>>
>>> desks = Desk.objects.filter(<filter here>).select_related('nearby_chairs', 'favorite_chairs')
>>>
>>> Then, you can modify your model with a property that will return the concatenation of nearby_chairs and favorite_chairs:
>>>
>>> class Desk(models.Model):
>>>     @property
>>>     def favorite_or_nearby_chairs(self):
>>>         return self.nearby_chairs.all() + self.favorite_chairs
>>>
>>> I don't believe this will spawn another query, since select_related() will have already run and have the results cached. You may also want to consider moving 'nearby_desks' out of Chair and renaming it to 'nearby_chairs' in Desk, and using a related_name of 'nearby_desks' instead. Then you can remove the .all() from the property definition from above and it definitely won't spawn a query. Obviously you'll need to create other processes that will populate desk.favorite_chairs, which may or may not be feasible.
>>>
>>> TL;DR; I don't believe you can pre-fetch anything because of the extra SQL logic needed to calculate the favorite_or_nearby_chairs attribute. It might be possible via raw SQL though. Reformatting your data models may lead to an easier time since you can then take advantage of the some of the optimizations Django offers.
>>>
>>> I'm slightly out in right field on this one, so YMMV, but taking a hard look at the current model design would be where I would start to try and eliminate the need for that custom queryset.
>>>
>>> Again, the django-debug-toolbar is your friend in these cases, but obviously a high number of even relatively fast queries can have a detrimental effect on your load times. Also ensure that the fields you are using to filter contain indexes, if appropriate/available.
>>>
>>> -James
>>>
>>>
>>>
>>>
>>> On Thu, Feb 26, 2015 at 10:17 AM, James Schneider <jrschneider83@gmail.com> wrote:
>>>>
>>>> Yep, looks like I misunderstood.
>>>>
>>>> So, you want to have something like this pseudo code:
>>>>
>>>> desks = Desk.objects.filter(<some filter>)
>>>> for desk in desks:
>>>>     print desk.favorite_or_nearby_chairs
>>>>
>>>> And have favorite_or_nearby_chairs be pre-populated with your Chair queryset mentioned earlier?
>>>>
>>>> Due to the nature of the custom Chair queryset, I doubt you can do any sort of pre-fetching that would reduce the number of queries. You can probably simulate the effect of prefetch_related() though by overriding the __init__() method of your Desk model, and having the Desk model populate favorite_or_nearby_chairs whenever a Desk object is created. 
>>>>
>>>> class Desk(models.Model)
>>>>     def __init__(self):
>>>>         # using list() to force the queryset to be evaluated
>>>>         self.favorite_or_nearby_chairs = list(<custom Chair queryset>)
>>>>
>>>>
>>>> However, that probably doesn't buy you much since you are still doing an extra query for every Desk you pull from your original query.
>>>>
>>>> Funny enough, I was googling around for an answer here, and stumbled across this:
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Feb 26, 2015 at 4:19 AM, aRkadeFR <contact@arkade.info> wrote:
>>>>>
>>>>> got it, so you want to prefetch but not all chairs.
>>>>>
>>>>> I will def follow this thread to see the possibilities of Prefetch :)
>>>>>
>>>>>
>>>>> On 02/26/2015 12:52 PM, Ram Rachum wrote:
>>>>>>
>>>>>> There may be a big number of chairs, and I don't want all the chairs prefetched. I want to have the database filter them according to the queryset I specified in a single call, I don't want to filter them in Python or make a new call to filter them.
>>>>>>
>>>>>> Thanks,
>>>>>> Ram.
>>>>>>
>>>>>> On Thu, Feb 26, 2015 at 1:48 PM, aRkadeFR <contact@arkade.info> wrote:
>>>>>>>
>>>>>>> I may not have completely understand your problem, but
>>>>>>> why not prefetching all the chairs? and then with the (new)
>>>>>>> attribute favorite_or_nearby_chairs loading only the favorite
>>>>>>> or nearby one?
>>>>>>>
>>>>>>> like:
>>>>>>> @property
>>>>>>> def favorite_or_nearby_chairs(self):
>>>>>>>     for chair in self.chair_set.all():
>>>>>>>           #filter...
>>>>>>>           ans += ...
>>>>>>>     return ans
>>>>>>>
>>>>>>> It will only hit the DB once thanks to the first join of desk
>>>>>>> <-> chair.
>>>>>>>
>>>>>>>
>>>>>>> On 02/26/2015 11:28 AM, cool-RR wrote:
>>>>>>>>
>>>>>>>> James, you misunderstood me.
>>>>>>>>
>>>>>>>> There isn't supposed to be a `favorite_or_nearby_chairs` attribute. That's the new attribute I want the prefetching to add to the `Desk` queryset that I need. Also, I don't understand why you'd tell me to add a `.select_related('nearby_desks')` to my query. Are you talking about the query that starts with `Chair.objects`? I'm not looking to get a `Chair` queryset. I'm looking to get a `Desk` queryset, which has a prefetched attribute `favorite_or_nearby_chairs` which contains the `Chair` queryset I wrote down.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Ram.
>>>>>>>>
>>>>>>>> On Thursday, February 26, 2015 at 6:02:15 AM UTC+2, James Schneider wrote:
>>>>>>>>>
>>>>>>>>> Well, the Desk model you provided is blank, but I'll believe you that there's a favorite_or_nearby_chairs attribute. ;-)
>>>>>>>>>
>>>>>>>>> Should be relatively simple. Just add a .select_related('nearby_desks') to your existing query and that should pull in the associated Desk object in a single query. You can also substitute in prefetch_related(), although you'll still have two queries at that point.
>>>>>>>>>
>>>>>>>>> If you are trying to profile your site, I would recommend the Django-debug-toolbar. That should tell you whether or not that query set is the culprit.
>>>>>>>>>
>>>>>>>>> -James
>>>>>>>>>
>>>>>>>>> On Feb 25, 2015 1:28 PM, "Ram Rachum" <r...@rachum.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi James,
>>>>>>>>>>
>>>>>>>>>> I've read the docs but I still couldn't figure it out. My queryset works great in production, I'm trying to optimize it because our pageloads are too slow. I know how to use querysets in Django pretty well, I just don't know how to use `Prefetch`. 
>>>>>>>>>>
>>>>>>>>>> Can you give me the solution for the simplified example I gave? This might help me figure out what I'm not understanding. One thing that might be unclear with the example I gave, is that I meant I want to get a queryset for `Desk` where every desk has an attribute names `favorite_or_nearby_chairs` which contains the queryset of chairs that I desrcibed, prefetched.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Ram.
>>>>>>>>>>
>>>>>>>>>> On Wed, Feb 25, 2015 at 11:18 PM, James Schneider <jrschn...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I assume that you are talking about the select_related() and prefetch_related() queryset methods?
>>>>>>>>>>>
>>>>>>>>>>> https://docs.djangoproject.com/en/1.7/ref/models/querysets/#select-related
>>>>>>>>>>> https://docs.djangoproject.com/en/1.7/ref/models/querysets/#prefetch-related
>>>>>>>>>>>
>>>>>>>>>>> Both of those sections have excellent examples, and detail what the differences are (primarily joins vs. separate queries, respectively).
>>>>>>>>>>>
>>>>>>>>>>> For better help, you'll need to go into more detail about the queries you are trying to make, what you've tried (with code examples if possible), and the results/errors you are seeing.
>>>>>>>>>>>
>>>>>>>>>>> In general, I would try to get an initial queryset working and gathering the correct results first before looking at optimizations such as select_related(). Any sort of pre-fetching will only confuse the situation if the base queryset is incorrect.
>>>>>>>>>>>
>>>>>>>>>>> -James
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Feb 25, 2015 at 12:05 PM, cool-RR <ram.r...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi guys,
>>>>>>>>>>>>
>>>>>>>>>>>> I'm trying to solve a problem using the new `Prefetch` but I can't figure out how to use it. 
>>>>>>>>>>>>
>>>>>>>>>>>> I have these models:
>>>>>>>>>>>>
>>>>>>>>>>>>     class Desk(django.db.models.Model):
>>>>>>>>>>>>         pass
>>>>>>>>>>>>     
>>>>>>>>>>>>     class Chair(django.db.models.Model):
>>>>>>>>>>>>         desk = django.db.models.Foreignkey('Desk', related_name='chair',)
>>>>>>>>>>>>         nearby_desks = django.db.models.ManyToManyField(
>>>>>>>>>>>>             'Desk',
>>>>>>>>>>>>             blank=True,
>>>>>>>>>>>>         )
>>>>>>>>>>>>
>>>>>>>>>>>> I want to get a queryset for `Desk`, but it should also include a prefetched attribute `favorite_or_nearby_chairs`, whose value should be equal to: 
>>>>>>>>>>>>
>>>>>>>>>>>>     Chair.objects.filter(
>>>>>>>>>>>>         (django.db.models.Q(nearby_desks=desk) | django.db.models.Q(desk=desk)),
>>>>>>>>>>>>         some_other_lookup=whatever,
>>>>>>>>>>>>     )
>>>>>>>>>>>>
>>>>>>>>>>>> Is this possible with `Prefetch`? I couldn't figure out how to use the arguments.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Ram.
>>>>>>>>>>>> --
>>>>>>>>>>>> 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...@googlegroups.com.
>>>>>>>>>>>> To post to this group, send email to django...@googlegroups.com.
>>>>>>>>>>>> Visit this group at http://groups.google.com/group/django-users.
>>>>>>>>>>>> To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/46d9fdb7-c008-4496-acda-ac7cb30b4a89%40googlegroups.com.
>>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
>>>>>>>>>>> To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/EuPduHjSNos/unsubscribe.
>>>>>>>>>>> To unsubscribe from this group and all its topics, send an email to django-users...@googlegroups.com.
>>>>>>>>>>> To post to this group, send email to django...@googlegroups.com.
>>>>>>>>>>> Visit this group at http://groups.google.com/group/django-users.
>>>>>>>>>>> To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Be%2BciVk7_6VBDoBE-qjLBwrBxiNeVdP6-fwwnOXV%3DvSA3HnCw%40mail.gmail.com.
>>>>>>>>>>>
>>>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> --
>>>>>>>> You received this message because you are subscribed to the Google Groups "Django users" group.
>>>>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@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.
>>>>>>>> To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/fc6b1237-7bd0-44a7-a91e-c12301fe0e05%40googlegroups.com.
>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> You received this message because you are subscribed to a topic in the Google Groups "Django users" group.
>>>>>>> To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-users/EuPduHjSNos/unsubscribe.
>>>>>>> To unsubscribe from this group and all its topics, send an email to django-users+unsubscribe@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.
>>>>>>> To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/54EF0808.9090009%40arkade.info.
>>>>>>>
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google Groups "Django users" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@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.
>>>>>> To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CANXboVa6%2BtSa5gmEww2-gm3SGHvGgn2VjOBTbYQA%3DWTt6CaufA%40mail.gmail.com.
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google Groups "Django users" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@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.
>>>>> To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/54EF0F3A.8000703%40arkade.info.
>>>>>
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@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.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Be%2BciU2Tnn6oX42%2Bn6Wpg8GRErcaoG9jp_2XCvYmUxDZaKRdw%40mail.gmail.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@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.
> To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/54F0300A.9000204%40arkade.info.
>
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@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.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Be%2BciVGNVZ0hkACb7MWjeVWUAXc6z6zrmhBTNCc8s-gJSRFVA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Problem installing and using smart_selects

Check the git repo, the issues page, one of the issues (I think the 4th) says that in the tittle, Can not import simple json.

You basically have to install it with pip but from the git branch, because they haven't updated pypy yet

On Sun, Mar 1, 2015, 6:32 PM Michael Ackary <mrsmellyhead@gmail.com> wrote:

Smart Selects looked so simple and promising for chained selects (https://github.com/digi604/django-smart-selects).  However, no matter how I install it, it doesn't seem to work.  Here is what I've tried:


Attempt #1 - putting it in django.contrib

Copied the smart_selects folder to /django/contrib/smart_selects

Added "django.contrib.smart_selects" to INSTALLED_APPS in settings.py

But within Django shell I got this error:

>>>  from django.contrib import smart_selects
>>>  smart_selects.urls
AttributeError: 'module' object has no attribute 'urls'



Attempt #2 - installed using pip

I removed the smart_selects folder from /django/contrib  folder (above) and then installed using pip... which put smart_selects in the Python site-packages folder.

But then trying to use smart_selects within urls.py produced an ugly "ImportError: cannot import name simplejson" which suggests smart_selects has some outdated dependencies. (I"m using Django 1.7).



Attemp #3 - putting smart_packages in the root folder of my Django project

When smart_selects is placed here, again I can import smart_selects from the Django shell  but not access smart-selects.urls :

Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> import smart_selects
>>> dir(smart_selects)
['__builtins__', '__doc__', '__file__', '__name__', '__package__', '__path__', 'models']
>>> smart_selects.urls
Traceback (most recent call last):
  File "<console>", line 1, in <module>
AttributeError: 'module' object has no attribute 'urls'


Finally it works if i do this:

>>> import smart_selects.urls
>>> smart_selects.urls
<module 'smart_selects.urls' from '/Users/chas/Projects/switch/djangoroot/smart_selects/urls.pyc'>


However, I really don't like putting apps here since they clutter up my own development (and would rather keep 3rd party apps in django/contrib). 

What am I missing about the smart_selects ?
Thank you,

Mike,

--
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+unsubscribe@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.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/1034ee57-88fc-417e-a9d6-b5787815ffb9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@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.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAAeX05HdBzzjNjydDuriti9tGGfr5DNmkme-dnpDizr9bRgfqw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Using proxy kind of Table in Admin Interface

Question.

How would one go about designing the django table(s) so that I can assign each user account/group a different Model Manager using the same table in the Django admin interface? 

After doing some reading the closest that comes to this is the Proxy Model but I tried adding the proxy model manually into the django admin and got an error while loading it. 

My goal is to create one table that returns a custom QuerySet unique to a user group or user account. Adding to this I would like for this to be visible in the admin interface. Can you guide me as to how can achieve this.

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+unsubscribe@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.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/cd13f5ab-633e-4361-a621-cfc11d5d01a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Different between Object-save and form-save

OK, thanks for the response. So the essence of the form_save() is to get the user object in which the password property can be set properly.
Thanks alot

On Mar 1, 2015 6:38 PM, "Vijay Khemlani" <vkhemlan@gmail.com> wrote:

Both save the user to the database, but "user_form.save()" leaves the user password in plain text (which won't work when the user tries to login later) so the password must be set correctly (user.set_password(user.password)) and then the user has to be saved again for the correct (hashed) password to be stored.

On Sun, Mar 1, 2015 at 12:57 PM, ADEWALE ADISA <solixzsystem@gmail.com> wrote:

Hi guys, pls help with little explanation on the extract below from tango tutorial. In the code, they call user_form().save() to save into database. Then latter call user.save(). Pls what's the different between the two ? Where did user.save() save to ?

from rango.forms import UserForm, UserProfileForm

def register(request):

    # A boolean value for telling the template whether the registration was successful.
    # Set to False initially. Code changes value to True when registration succeeds.
    registered = False

    # If it's a HTTP POST, we're interested in processing form data.
    if request.method == 'POST':
        # Attempt to grab information from the raw form information.
        # Note that we make use of both UserForm and UserProfileForm.
        user_form = UserForm(data=request.POST)
        profile_form = UserProfileForm(data=request.POST)

        # If the two forms are valid...
        if user_form.is_valid() and profile_form.is_valid():
            # Save the user's form data to the database.
            user = user_form.save()

            # Now we hash the password with the set_password method.
            # Once hashed, we can update the user object.
            user.set_password(user.password)
            user.save()

            # Now sort out the UserProfile instance.
            # Since we need to set the user attribute ourselves, we set commit=False.
            # This delays saving the model until we're ready to avoid integrity problems.
            profile = profile_form.save(commit=False)
            profile.user = user

--
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+unsubscribe@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.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAMGzuy_saD%3DscV_CJtKzcss2siPktvFxi1oCUD-BvCEURtA5jg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@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.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CALn3ei34SRTYAxP4oaSExM2Nt-tjym4PXP2q2xuSgkkH8TV_UA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@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.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAMGzuy8aX8ehs4Qd2RgkueERA-OmDQg8gbE%3DVxJCB8heKw%2B03A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.