Re: Database Transaction

[Javier Guerra Giraldez]

On Tue, Jan 22, 2013 at 11:54 AM, Sandeep kaur  wrote:
> Yes, I also thought south will be helpful but when we need to do
> complete migration like old table is without foreign keys but new
> table has foreign keys etc. then I could not understand how to use
> south. Can you provide me some tutorial for the same.


I haven't used South for complex data migrations, but I think it's
most useful just after (or simultaneously to) doing the schema
migration with South.  In your case, you sound like you haven't done
any real schema migration, more like a reimplementation.

(( unless it is just a change to the application and your talk about
"new application" and "old application" means just that you're not
using any version control system.  in that case, no matter what i
advice here, you're already in deep trouble ))

if you've done a real reimplementation, then I don't think there's any
tool to do much help.  you have to write a third application that
reads data in the old representation and writes in the new one.  and
run that app once.

of course, if both old and new applications are written with Django
and handle data via the Django ORM, then you can do things like:


import oldapp.models
import newapp.models

for oldrec in oldapp.models.MyModel.objects.all():
newapp.models.MyNewModel.create (newfield=oldrec.oldfield,..)


and so on.

--
Javier

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

Re: What's the right pattern to re-use common view code?

[andrew jackson]

...I can't believe i missed that as a builtin.  Sorry!

Thank you very much!
-andrew

On Tuesday, January 22, 2013 12:01:52 PM UTC-8, Nikolas Stevenson-Molnar 
wrote:
>
>  Django does {% include %} too :) 
> https://docs.djangoproject.com/en/1.4/ref/templates/builtins/#include
>
> You could do something like: {% include "book_list.html" with 
> books=auth.book_set.all %}
>
> _Nik
>
> On 1/22/2013 8:03 AM, andrew jackson wrote:
>  
> I have an object that shows up in lots of different parts of the system, 
> say a Book.   
>
>  I want to display a list view of Book objects in many different places, 
> e.g.,  
>
> When looking at an Author's detail page, I want to see a list of recent 
> books they've written
>  when looking at a publisher page, similar.
> In fact, even when looking at a book i'd like to have a list of books that 
> reference it.
>
>  So, there's going to be html code that shows a table of books on several 
> different pages.
>
>  My question is, what's the right way to follow DRY w/ django templates 
> and not duplicate the code that makes a list of books?  
>
>  If I was using Jinja, it'd be pretty straightforward to {% include %} a 
> snippet in each page that renders each queryset as a fancy table.  It 
> doesn't look like template inheritance is set up that way here, though.
>
>  So what's the right way to do it with Django?  Am I thinking about it 
> wrong?  I see a few django-fancy-tables plugins, but they seem pretty 
> heavyweight, and i'd like to understand the right way to approach the 
> solution here.  In fact, I don't even know the right words to use to 
> describe the problem, so my google-fu is weak.  Do I write a custom 
> template tag that takes a queryset as a parameter?  Aren't custom template 
> tags to be avoided?
>  
>  
>  Thanks much for your time,
> Andrew
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/django-users/-/TRxMsFf3sN0J.
> To post to this group, send email to django...@googlegroups.com
> .
> To unsubscribe from this group, send email to 
> django-users...@googlegroups.com .
> For more options, visit this group at 
> http://groups.google.com/group/django-users?hl=en.
>
>
>  

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

Re: Struggling with slow startup / SQL in new app (using raw SQL)

[Matt Andrews]

Yes, local app, local DB (which is an exact copy of the production DB). 
Interestingly, I just tried pointing the local app at the remote database 
and total query time (for 10 queries) went from 115ms to 3477ms! Really odd.

On Tuesday, January 22, 2013 7:54:53 PM UTC, Nikolas Stevenson-Molnar wrote:
>
>  When running locally, are you also using a local database instance? IIRC 
> the time that phpMyAdmin reports is the time taken for the database to 
> execute the query, whereas the time reported by the debug toolbar (I *
> think*) is complete round-trip (send query, execute, return results). So 
> if there is latency between your application and your database, that could 
> account for the discrepancy.
>
> The debug toolbar *does* add overhead to your request (about doubles the 
> page load time), but the numbers it reports should be more or less accurate 
> (iow a page might take 1s to load with the toolbar, but the toolbar will 
> report 500ms, which is accurate for load-time *without* the toolbar).
>
> _Nik
>
> On 1/22/2013 9:26 AM, Matt Andrews wrote:
>  
> Hi Nik, 
>
>  I see the discrepancy both locally and when deployed, too -- that's 
> what's so puzzling. If it helps, I'm using MySQL and running it on Windows 
> locally and under Passenger on my remote Linux server (also on MySQL).
>
>  Only other thing I can think of is that this "overhead" might literally 
> be the extra work Django Debug Toolbar does to show queries etc. Obviously 
> when I turn the toolbar off then I can't see (directly) the SQL times 
> Django is getting, but could be a factor? Either way, with the toolbar off 
> on production, there's definitely a slight "lag" before page requests start 
> to kick in -- maybe this is unrelated to the SQL, though.
>
>
> On Tuesday, 22 January 2013 16:42:19 UTC, Nikolas Stevenson-Molnar wrote: 
>>
>> Hi Matt, 
>>
>>  It's unlikely the problem lies with dictfetchall. The "small 
>> performance hit" mentioned by the docs probably refers to the fact that the 
>> function has a time complexity of (number of colulmns) * (number of rows). 
>> Since you're only getting 10 rows back, I can't see that having an 
>> appreciable impact.
>>
>>  I haven't seen this kind of variation between performing a direct 
>> query, and executing the query as part of a Django request… especially with 
>> such a basic query. Do you see the same difference in timing locally or is 
>> it only when deployed?
>>
>>  _Nik
>>
>>  On Jan 22, 2013, at 4:47 AM, Matt Andrews  
>> wrote:
>>
>> That looks really useful - for future reference, great! Sadly my webhost 
>> is still bundling Django 1.2.3 :( 
>>
>>  In general, though, these issues still come down to the fact that a SQL 
>> query as executed by Django takes several times longer than going directly 
>> to the DB. Is this down to my use of dictfetchall() or something more low 
>> level?
>>
>>
>> On Tuesday, January 22, 2013 12:09:50 PM UTC, Jani Tiainen wrote: 
>>>
>>> Hi, 
>>>
>>> I see that you had quite a bunch of m2m keys. 
>>>
>>> Have you tried recent version of Django (1.4+) with prefetch_related() 
>>> [1] ? 
>>>
>>>
>>> [1] 
>>> <
>>> https://docs.djangoproject.com/en/1.4/ref/models/querysets/#prefetch-related>
>>>  
>>>
>>>
>>>
>>> 22.1.2013 13:57, Matt Andrews kirjoitti: 
>>> > Hi Jani, 
>>> > 
>>> > I made a StackOverflow post last year with an example of the ORM stuff 
>>> I 
>>> > tried and the poor queries it produced: 
>>> > 
>>> http://stackoverflow.com/questions/5843457/django-objects-all-making-360-queries-how-can-i-optimise-this-manytomany
>>>  
>>> > 
>>> > There's also this discussion about how using the same queryset in two 
>>> > places in the template caused Django to request its data twice: 
>>> > 
>>> http://stackoverflow.com/questions/9447053/best-way-to-slice-a-django-queryset-without-hitting-the-database-more-than-once(this
>>>  
>>> > was easily fixed, but again, not very intuitive and frustrated me) 
>>> > 
>>> > I don't have the data to hand currently but I also remember seeing 
>>> weird 
>>> > things happen where queries would end with stuff like "... LIMIT 
>>> > 234423445" (or some crazy number which I'd never entered and was 
>>> orders 
>>> > of magnitude bigger than the number of rows in the table). 
>>> > 
>>> > I'm aware these are probably edge cases that are down to my own novice 
>>> > status, but even using things like select_related(), it wasn't doing 
>>> > what I wanted. I just felt it easier to use my existing SQL (I'm 
>>> > converting a PHP app over to Django) and I'm not concerned about 
>>> > database portability (switching to postgres or whatever). 
>>> > 
>>> > Nik: just realised I missed your final question. For the SQL posted 
>>> > above, the numbers are approximately: 12,000 rows in the `news` table, 
>>> > maybe 10 `news_category` rows, about 100 `writers` and around 3000 
>>> > `images`. All properly indexed and with sensible column types. 
>>> > 
>>> > On Tuesday, January 22, 2013 

Re: Can I set a "global" variable after user login, to use in my view?

[Tomas Neme]

vUserProfile=request.user.profile
or
vUserProfile=request.user.get_profile()
to be more flexible



On Tue, Jan 22, 2013 at 5:01 PM, Fellipe Henrique wrote:

> The problem is, I need to pass this request.user to one form, using a
> inlineformset_factory..in these code:
>
> class PedidoItensForm(ModelForm):
> class Meta:
> model = ItensPedido
>
> def __init__(self, *args, **kwargs):
> profile = kwargs.pop('vUserProfile', None)
> super(PedidoItensForm, self).__init__(*args, **kwargs)
> self.fields["idproduto"].queryset =
> Produto.objects.filter(idempresa=profile.idempresa)
>
> I need to pass UserProfile to my form, to get works my filter.
>
> If I use inlineformset_factory, how can I pass the vUserProfile ?
>
>
> Thanks
>
> T.·.F.·.A.·. S+F
> *Fellipe Henrique P. Soares*
>
> *"Quemadmodum gladius neminem occidit, occidentis telum est."* (Epistulae
> morales ad 
> Lucilium,
> Lucius Annaeus Seneca)
>
> *"Any intelligent fool can make things bigger, more complex, and more
> violent. It takes a touch of genius -- and a lot of courage -- to move in
> the opposite direction."*
> Albert Einstein (March 14th 1879 – April 18th 1955)
>
>
> 2013/1/22 Tomas Neme 
>
>>
>>
>> what mengu says is good for templates, but not so for views.
>>
>> But lo! your request should have a .user property that points to the
>> currently logged user, so try
>>
>> request.user
>>
>> in your view
>>
>>
>> On Tue, Jan 22, 2013 at 4:49 PM, Mengu  wrote:
>>
>>> hi fellipe,
>>>
>>> if you enable auth context processors and pass in RequestContext to
>>> render_to_response you can always access the user in your templates
>>> which also means you can access the associated profile as user.profile
>>> (assuming your model is named profile)
>>>
>>> please read more at
>>> https://docs.djangoproject.com/en/dev/topics/auth/default/#authentication-data-in-templates
>>>
>>>
>>>
>>> On Jan 22, 8:34 pm, Fellipe Henrique  wrote:
>>> > Hello,
>>> >
>>> > It's possible, when the user make a login, I set one "global"
>>> variable, and
>>> > get this value in my view?
>>> >
>>> > My question is because I have a inlineformset_factory, and I need to
>>> pass a
>>> > user profile do my view.. but it`s doesn't work.
>>> >
>>> > Regards,
>>> >
>>> > T.·.F.·.A.·. S+F
>>> > *Fellipe Henrique P. Soares*
>>> >
>>> > *"Quemadmodum gladius neminem occidit, occidentis telum est."*
>>> (Epistulae
>>> > morales ad Lucilium<
>>> http://en.wikipedia.org/wiki/Epistulae_morales_ad_Lucilium>,
>>> > Lucius Annaeus Seneca)
>>> >
>>> > *"Any intelligent fool can make things bigger, more complex, and more
>>> > violent. It takes a touch of genius -- and a lot of courage -- to move
>>> in
>>> > the opposite direction."*
>>> > Albert Einstein (March 14th 1879 – April 18th 1955)
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django users" group.
>>> To post to this group, send email to django-users@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> django-users+unsubscr...@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/django-users?hl=en.
>>>
>>>
>>
>>
>> --
>> "The whole of Japan is pure invention. There is no such country, there
>> are no such people" --Oscar Wilde
>>
>> |_|0|_|
>> |_|_|0|
>> |0|0|0|
>>
>> (\__/)
>> (='.'=)This is Bunny. Copy and paste bunny
>> (")_(") to help him gain world domination.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To post to this group, send email to django-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-users?hl=en.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>



-- 
"The whole of Japan is pure invention. There is no such country, there are
no such people" --Oscar Wilde

|_|0|_|
|_|_|0|
|0|0|0|

(\__/)
(='.'=)This is Bunny. Copy and paste bunny
(")_(") to help him gain world domination.

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

Re: Django-SEO issue

[Jonathan D. Baker]

I wasn't. If anyone has a solution I'd still be interested in cleaning
up the clutter and removing the backends I'm not using.

On 01/22/2013 12:05 PM, Jeff Ammons wrote:
> Were you able to figure out what was happening here? I'm experiencing
> the same issue.
>
> On Friday, August 17, 2012 2:16:53 PM UTC-6, jondbaker wrote:
>
> I've successfully installed Django-SEO, but when I try to limit
> the number of backends (I only need/want my admin to have 'path'
> and not the other three) I am met with the following error:
>
>
>   AttributeError at /admin/
>
>
>   'NoneType' object has no attribute '_meta'
>
>
> I am using the documentation
> here: 
> http://django-seo.readthedocs.org/en/latest/reference/definition.html#Meta.backends
> 
> 
>
> *seo.py*
> from rollyourown import seo
>
> class AppMetadata(seo.Metadata):
> title = seo.Tag(head=True, max_length=68)
> description = seo.MetaTag(max_length=155)
>
> class Meta:
> backends = ('path',)
> #backends = ('path', 'modelinstance', 'model', 'view',)
> This works but includes all default backends
>
> *admin.py*
> from django.contrib import admin
> from rollyourown.seo.admin import register_seo_admin
>
> from localsite.seo import AppMetadata
>
> register_seo_admin(admin.site, AppMetadata)
>
> -- 
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/gB5-ZyRCpHIJ.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.


-- 
Software Developer
https://github.com/jondbaker
GPG: 1F6F3FFD

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

Re: Can I set a "global" variable after user login, to use in my view?

[Fellipe Henrique]

The problem is, I need to pass this request.user to one form, using a
inlineformset_factory..in these code:

class PedidoItensForm(ModelForm):
class Meta:
model = ItensPedido

def __init__(self, *args, **kwargs):
profile = kwargs.pop('vUserProfile', None)
super(PedidoItensForm, self).__init__(*args, **kwargs)
self.fields["idproduto"].queryset =
Produto.objects.filter(idempresa=profile.idempresa)

I need to pass UserProfile to my form, to get works my filter.

If I use inlineformset_factory, how can I pass the vUserProfile ?


Thanks

T.·.F.·.A.·. S+F
*Fellipe Henrique P. Soares*

*"Quemadmodum gladius neminem occidit, occidentis telum est."* (Epistulae
morales ad Lucilium,
Lucius Annaeus Seneca)

*"Any intelligent fool can make things bigger, more complex, and more
violent. It takes a touch of genius -- and a lot of courage -- to move in
the opposite direction."*
Albert Einstein (March 14th 1879 – April 18th 1955)


2013/1/22 Tomas Neme 

>
>
> what mengu says is good for templates, but not so for views.
>
> But lo! your request should have a .user property that points to the
> currently logged user, so try
>
> request.user
>
> in your view
>
>
> On Tue, Jan 22, 2013 at 4:49 PM, Mengu  wrote:
>
>> hi fellipe,
>>
>> if you enable auth context processors and pass in RequestContext to
>> render_to_response you can always access the user in your templates
>> which also means you can access the associated profile as user.profile
>> (assuming your model is named profile)
>>
>> please read more at
>> https://docs.djangoproject.com/en/dev/topics/auth/default/#authentication-data-in-templates
>>
>>
>>
>> On Jan 22, 8:34 pm, Fellipe Henrique  wrote:
>> > Hello,
>> >
>> > It's possible, when the user make a login, I set one "global" variable,
>> and
>> > get this value in my view?
>> >
>> > My question is because I have a inlineformset_factory, and I need to
>> pass a
>> > user profile do my view.. but it`s doesn't work.
>> >
>> > Regards,
>> >
>> > T.·.F.·.A.·. S+F
>> > *Fellipe Henrique P. Soares*
>> >
>> > *"Quemadmodum gladius neminem occidit, occidentis telum est."*
>> (Epistulae
>> > morales ad Lucilium<
>> http://en.wikipedia.org/wiki/Epistulae_morales_ad_Lucilium>,
>> > Lucius Annaeus Seneca)
>> >
>> > *"Any intelligent fool can make things bigger, more complex, and more
>> > violent. It takes a touch of genius -- and a lot of courage -- to move
>> in
>> > the opposite direction."*
>> > Albert Einstein (March 14th 1879 – April 18th 1955)
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To post to this group, send email to django-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-users?hl=en.
>>
>>
>
>
> --
> "The whole of Japan is pure invention. There is no such country, there are
> no such people" --Oscar Wilde
>
> |_|0|_|
> |_|_|0|
> |0|0|0|
>
> (\__/)
> (='.'=)This is Bunny. Copy and paste bunny
> (")_(") to help him gain world domination.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>

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

Re: What's the right pattern to re-use common view code?

[Nikolas Stevenson-Molnar]

Django does {% include %} too :)
https://docs.djangoproject.com/en/1.4/ref/templates/builtins/#include

You could do something like: {% include "book_list.html" with
books=auth.book_set.all %}

_Nik

On 1/22/2013 8:03 AM, andrew jackson wrote:
> I have an object that shows up in lots of different parts of the
> system, say a Book.  
>
> I want to display a list view of Book objects in many different
> places, e.g., 
>
> When looking at an Author's detail page, I want to see a list of
> recent books they've written
> when looking at a publisher page, similar.
> In fact, even when looking at a book i'd like to have a list of books
> that reference it.
>
> So, there's going to be html code that shows a table of books on
> several different pages.
>
> My question is, what's the right way to follow DRY w/ django templates
> and not duplicate the code that makes a list of books?  
>
> If I was using Jinja, it'd be pretty straightforward to {% include %}
> a snippet in each page that renders each queryset as a fancy table.
>  It doesn't look like template inheritance is set up that way here,
> though.
>
> So what's the right way to do it with Django?  Am I thinking about it
> wrong?  I see a few django-fancy-tables plugins, but they seem pretty
> heavyweight, and i'd like to understand the right way to approach the
> solution here.  In fact, I don't even know the right words to use to
> describe the problem, so my google-fu is weak.  Do I write a custom
> template tag that takes a queryset as a parameter?  Aren't custom
> template tags to be avoided?
>
>
> Thanks much for your time,
> Andrew
> -- 
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/TRxMsFf3sN0J.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.

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

Re: Can I set a "global" variable after user login, to use in my view?

[Tomas Neme]

what mengu says is good for templates, but not so for views.

But lo! your request should have a .user property that points to the
currently logged user, so try

request.user

in your view


On Tue, Jan 22, 2013 at 4:49 PM, Mengu  wrote:

> hi fellipe,
>
> if you enable auth context processors and pass in RequestContext to
> render_to_response you can always access the user in your templates
> which also means you can access the associated profile as user.profile
> (assuming your model is named profile)
>
> please read more at
> https://docs.djangoproject.com/en/dev/topics/auth/default/#authentication-data-in-templates
>
>
>
> On Jan 22, 8:34 pm, Fellipe Henrique  wrote:
> > Hello,
> >
> > It's possible, when the user make a login, I set one "global" variable,
> and
> > get this value in my view?
> >
> > My question is because I have a inlineformset_factory, and I need to
> pass a
> > user profile do my view.. but it`s doesn't work.
> >
> > Regards,
> >
> > T.·.F.·.A.·. S+F
> > *Fellipe Henrique P. Soares*
> >
> > *"Quemadmodum gladius neminem occidit, occidentis telum est."* (Epistulae
> > morales ad Lucilium<
> http://en.wikipedia.org/wiki/Epistulae_morales_ad_Lucilium>,
> > Lucius Annaeus Seneca)
> >
> > *"Any intelligent fool can make things bigger, more complex, and more
> > violent. It takes a touch of genius -- and a lot of courage -- to move in
> > the opposite direction."*
> > Albert Einstein (March 14th 1879 – April 18th 1955)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>


-- 
"The whole of Japan is pure invention. There is no such country, there are
no such people" --Oscar Wilde

|_|0|_|
|_|_|0|
|0|0|0|

(\__/)
(='.'=)This is Bunny. Copy and paste bunny
(")_(") to help him gain world domination.

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

Re: Struggling with slow startup / SQL in new app (using raw SQL)

[Nikolas Stevenson-Molnar]

When running locally, are you also using a local database instance? IIRC
the time that phpMyAdmin reports is the time taken for the database to
execute the query, whereas the time reported by the debug toolbar (I
/think/) is complete round-trip (send query, execute, return results).
So if there is latency between your application and your database, that
could account for the discrepancy.

The debug toolbar /does/ add overhead to your request (about doubles the
page load time), but the numbers it reports should be more or less
accurate (iow a page might take 1s to load with the toolbar, but the
toolbar will report 500ms, which is accurate for load-time /without/ the
toolbar).

_Nik

On 1/22/2013 9:26 AM, Matt Andrews wrote:
> Hi Nik,
>
> I see the discrepancy both locally and when deployed, too -- that's
> what's so puzzling. If it helps, I'm using MySQL and running it on
> Windows locally and under Passenger on my remote Linux server (also on
> MySQL).
>
> Only other thing I can think of is that this "overhead" might
> literally be the extra work Django Debug Toolbar does to show queries
> etc. Obviously when I turn the toolbar off then I can't see (directly)
> the SQL times Django is getting, but could be a factor? Either way,
> with the toolbar off on production, there's definitely a slight "lag"
> before page requests start to kick in -- maybe this is unrelated to
> the SQL, though.
>
>
> On Tuesday, 22 January 2013 16:42:19 UTC, Nikolas Stevenson-Molnar wrote:
>
> Hi Matt,
>
> It's unlikely the problem lies with dictfetchall. The "small
> performance hit" mentioned by the docs probably refers to the fact
> that the function has a time complexity of (number of colulmns) *
> (number of rows). Since you're only getting 10 rows back, I can't
> see that having an appreciable impact.
>
> I haven't seen this kind of variation between performing a direct
> query, and executing the query as part of a Django request...
> especially with such a basic query. Do you see the same difference
> in timing locally or is it only when deployed?
>
> _Nik
>
> On Jan 22, 2013, at 4:47 AM, Matt Andrews  > wrote:
>
>> That looks really useful - for future reference, great! Sadly my
>> webhost is still bundling Django 1.2.3 :(
>>
>> In general, though, these issues still come down to the fact that
>> a SQL query as executed by Django takes several times longer than
>> going directly to the DB. Is this down to my use of
>> dictfetchall() or something more low level?
>>
>>
>> On Tuesday, January 22, 2013 12:09:50 PM UTC, Jani Tiainen wrote:
>>
>> Hi,
>>
>> I see that you had quite a bunch of m2m keys.
>>
>> Have you tried recent version of Django (1.4+) with
>> prefetch_related() [1] ?
>>
>>
>> [1]
>> 
>> > 
>> >
>>
>>
>>
>> 22.1.2013 13:57, Matt Andrews kirjoitti:
>> > Hi Jani,
>> >
>> > I made a StackOverflow post last year with an example of
>> the ORM stuff I
>> > tried and the poor queries it produced:
>> >
>> 
>> http://stackoverflow.com/questions/5843457/django-objects-all-making-360-queries-how-can-i-optimise-this-manytomany
>> 
>> 
>>
>> >
>> > There's also this discussion about how using the same
>> queryset in two
>> > places in the template caused Django to request its data
>> twice:
>> >
>> 
>> http://stackoverflow.com/questions/9447053/best-way-to-slice-a-django-queryset-without-hitting-the-database-more-than-once
>> 
>> 
>> (this
>> > was easily fixed, but again, not very intuitive and
>> frustrated me)
>> >
>> > I don't have the data to hand currently but I also remember
>> seeing weird
>> > things happen where queries would end with stuff like "...
>> LIMIT
>> > 234423445" (or some crazy number which I'd never entered
>> and was orders
>> > of magnitude bigger than the number of rows in the table).
>> >
>> > I'm aware these are probably edge cases that are down to my
>> own novice
>> > status, but even using things like select_related(), it
>> wasn't doing
>> > what I wanted. I just felt it easier to use my existing SQL
>> (I'm
>> > converting a PHP app over to Django) and I'm not concerned
>> about
>> > database portability (switching to postgres or whatever).
>>   

Re: Upload multiple files using Ajax

[Mengu]

i used jquery.form plugin back in the day. it worked great but it had
issues with large files.

check out http://malsup.com/jquery/form/progress3.html and
http://malsup.com/jquery/form/

On Jan 22, 6:05 pm, Andre Lopes  wrote:
> Hi,
>
> I need to develop a form to upload multiple files.
>
> I was thinking in using an Ajax uploader. I have google some options
> but there are to many and I don't know which one to choose.
>
> Any recommendations about this subject?
>
> Best Regards,
> André.

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

Re: Can I set a "global" variable after user login, to use in my view?

[Mengu]

hi fellipe,

if you enable auth context processors and pass in RequestContext to
render_to_response you can always access the user in your templates
which also means you can access the associated profile as user.profile
(assuming your model is named profile)

please read more at 
https://docs.djangoproject.com/en/dev/topics/auth/default/#authentication-data-in-templates



On Jan 22, 8:34 pm, Fellipe Henrique  wrote:
> Hello,
>
> It's possible, when the user make a login, I set one "global" variable, and
> get this value in my view?
>
> My question is because I have a inlineformset_factory, and I need to pass a
> user profile do my view.. but it`s doesn't work.
>
> Regards,
>
> T.·.F.·.A.·.     S+F
> *Fellipe Henrique P. Soares*
>
> *"Quemadmodum gladius neminem occidit, occidentis telum est."* (Epistulae
> morales ad 
> Lucilium,
> Lucius Annaeus Seneca)
>
> *"Any intelligent fool can make things bigger, more complex, and more
> violent. It takes a touch of genius -- and a lot of courage -- to move in
> the opposite direction."*
> Albert Einstein (March 14th 1879 – April 18th 1955)

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

Re: Django-SEO issue

[Jeff Ammons]

Were you able to figure out what was happening here? I'm experiencing the 
same issue.

On Friday, August 17, 2012 2:16:53 PM UTC-6, jondbaker wrote:
>
> I've successfully installed Django-SEO, but when I try to limit the number 
> of backends (I only need/want my admin to have 'path' and not the other 
> three) I am met with the following error:
> AttributeError at /admin/'NoneType' object has no attribute '_meta'
>
> I am using the documentation here: 
> http://django-seo.readthedocs.org/en/latest/reference/definition.html#Meta.backends
>
> *seo.py*
> from rollyourown import seo
>
> class AppMetadata(seo.Metadata):
> title = seo.Tag(head=True, max_length=68)
> description = seo.MetaTag(max_length=155)
>
> class Meta:
> backends = ('path',)
> #backends = ('path', 'modelinstance', 'model', 'view',) This works 
> but includes all default backends
>
> *admin.py*
> from django.contrib import admin
> from rollyourown.seo.admin import register_seo_admin
>
> from localsite.seo import AppMetadata
>
> register_seo_admin(admin.site, AppMetadata)
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/gB5-ZyRCpHIJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Can I set a "global" variable after user login, to use in my view?

[Fellipe Henrique]

Hello,

It's possible, when the user make a login, I set one "global" variable, and
get this value in my view?

My question is because I have a inlineformset_factory, and I need to pass a
user profile do my view.. but it`s doesn't work.

Regards,

T.·.F.·.A.·. S+F
*Fellipe Henrique P. Soares*

*"Quemadmodum gladius neminem occidit, occidentis telum est."* (Epistulae
morales ad Lucilium,
Lucius Annaeus Seneca)

*"Any intelligent fool can make things bigger, more complex, and more
violent. It takes a touch of genius -- and a lot of courage -- to move in
the opposite direction."*
Albert Einstein (March 14th 1879 – April 18th 1955)

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

Re: Struggling with slow startup / SQL in new app (using raw SQL)

[Matt Andrews]

Hi Nik,

I see the discrepancy both locally and when deployed, too -- that's what's 
so puzzling. If it helps, I'm using MySQL and running it on Windows locally 
and under Passenger on my remote Linux server (also on MySQL).

Only other thing I can think of is that this "overhead" might literally be 
the extra work Django Debug Toolbar does to show queries etc. Obviously 
when I turn the toolbar off then I can't see (directly) the SQL times 
Django is getting, but could be a factor? Either way, with the toolbar off 
on production, there's definitely a slight "lag" before page requests start 
to kick in -- maybe this is unrelated to the SQL, though.


On Tuesday, 22 January 2013 16:42:19 UTC, Nikolas Stevenson-Molnar wrote:
>
> Hi Matt,
>
> It's unlikely the problem lies with dictfetchall. The "small performance 
> hit" mentioned by the docs probably refers to the fact that the function 
> has a time complexity of (number of colulmns) * (number of rows). Since 
> you're only getting 10 rows back, I can't see that having an appreciable 
> impact.
>
> I haven't seen this kind of variation between performing a direct query, 
> and executing the query as part of a Django request… especially with such a 
> basic query. Do you see the same difference in timing locally or is it only 
> when deployed?
>
> _Nik
>
> On Jan 22, 2013, at 4:47 AM, Matt Andrews 
>  
> wrote:
>
> That looks really useful - for future reference, great! Sadly my webhost 
> is still bundling Django 1.2.3 :(
>
> In general, though, these issues still come down to the fact that a SQL 
> query as executed by Django takes several times longer than going directly 
> to the DB. Is this down to my use of dictfetchall() or something more low 
> level?
>
>
> On Tuesday, January 22, 2013 12:09:50 PM UTC, Jani Tiainen wrote:
>>
>> Hi, 
>>
>> I see that you had quite a bunch of m2m keys. 
>>
>> Have you tried recent version of Django (1.4+) with prefetch_related() 
>> [1] ? 
>>
>>
>> [1] 
>> <
>> https://docs.djangoproject.com/en/1.4/ref/models/querysets/#prefetch-related>
>>  
>>
>>
>>
>> 22.1.2013 13:57, Matt Andrews kirjoitti: 
>> > Hi Jani, 
>> > 
>> > I made a StackOverflow post last year with an example of the ORM stuff 
>> I 
>> > tried and the poor queries it produced: 
>> > 
>> http://stackoverflow.com/questions/5843457/django-objects-all-making-360-queries-how-can-i-optimise-this-manytomany
>>  
>> > 
>> > There's also this discussion about how using the same queryset in two 
>> > places in the template caused Django to request its data twice: 
>> > 
>> http://stackoverflow.com/questions/9447053/best-way-to-slice-a-django-queryset-without-hitting-the-database-more-than-once(this
>>  
>> > was easily fixed, but again, not very intuitive and frustrated me) 
>> > 
>> > I don't have the data to hand currently but I also remember seeing 
>> weird 
>> > things happen where queries would end with stuff like "... LIMIT 
>> > 234423445" (or some crazy number which I'd never entered and was orders 
>> > of magnitude bigger than the number of rows in the table). 
>> > 
>> > I'm aware these are probably edge cases that are down to my own novice 
>> > status, but even using things like select_related(), it wasn't doing 
>> > what I wanted. I just felt it easier to use my existing SQL (I'm 
>> > converting a PHP app over to Django) and I'm not concerned about 
>> > database portability (switching to postgres or whatever). 
>> > 
>> > Nik: just realised I missed your final question. For the SQL posted 
>> > above, the numbers are approximately: 12,000 rows in the `news` table, 
>> > maybe 10 `news_category` rows, about 100 `writers` and around 3000 
>> > `images`. All properly indexed and with sensible column types. 
>> > 
>> > On Tuesday, January 22, 2013 10:53:40 AM UTC, Jani Tiainen wrote: 
>> > 
>> > Hi, 
>> > 
>> >   From your raw SQL I saw you're doing few joins. So I suppose you 
>> do 
>> > quite a few foreign key fetches. 
>> > 
>> > You didn't mention anything how you originally tried to solve case 
>> with 
>> > ORM. Could you please publish what you had when things were slow? 
>> > 
>> > 22.1.2013 12:26, Matt Andrews kirjoitti: 
>> >  > Hi Nik, 
>> >  > 
>> >  > Thanks - I do feel like by circumventing the ORM I've just 
>> "given 
>> > up" 
>> >  > and perhaps I'll reconsider -- none of my queries are 
>> particularly 
>> >  > "specialist" (as the sample above indicates) - I just found 
>> Django 
>> >  > generating odd things. 
>> >  > 
>> >  > To answer your questions: 
>> >  > 
>> >  > 1. Yes, reloading the page sees the same time for the queries 
>> (it 
>> > just 
>> >  > feels as though the entire process takes a second or two to 
>> > start, which 
>> >  > is perhaps not related to SQL itself). 
>> >  > 
>> >  > 2. I believe so, yes (it's shared hosting...). 
>> >  > 
>> >  > If you're curious, you can see a sample 

Re: saving get objects to models

[Satinderpal Singh]

>> material = Material.objects.get(name=request.GET['material'])
>>
> I think this will help you :
> p = table(material =material, ...[other fields of table to be saved])
> p.save()

Thanks, this works for me.

> Here table is your table where you want object value to be saved.
> Hope this helps you.

--
Satinderpal Singh
http://satindergoraya.blogspot.in/
http://satindergoraya91.blogspot.in/

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

Re: Database Transaction

[Sandeep kaur]

On Tue, Jan 22, 2013 at 7:32 PM, Javier Guerra Giraldez
 wrote:
> On Mon, Jan 21, 2013 at 10:03 PM, Jian Chang  wrote:
>> you can't do the transaction between two different databases.
>
> i think the OP is talking about translation and not transaction.  as
> in translating the data from an old representation to the new one.  a
> better word might be migration.
>
Yes, sorry for creating gap in communication.

> of course, that's totally specific to his own code.  i don't think
> there's much generic advise to give, beyond trying South's
> datamigration facilities.  (which might not be the easiest way if the
> representations are so different)
>
Yes, I also thought south will be helpful but when we need to do
complete migration like old table is without foreign keys but new
table has foreign keys etc. then I could not understand how to use
south. Can you provide me some tutorial for the same.
Thank you.

-- 
Sandeep Kaur
E-Mail: mkaurkha...@gmail.com
Blog: sandymadaan.wordpress.com

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

Re: saving get objects to models

[Sandeep kaur]

On Tue, Jan 22, 2013 at 8:39 PM, Satinderpal Singh
 wrote:
> How to save the objects to models without using form. I tried to save
> the name object to the model, but unable to do so,
>
> material = Material.objects.get(name=request.GET['material'])
>
I think this will help you :
p = table(material =material, ...[other fields of table to be saved])
p.save()

Here table is your table where you want object value to be saved.
Hope this helps you.

-- 
Sandeep Kaur
E-Mail: mkaurkha...@gmail.com
Blog: sandymadaan.wordpress.com

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

Re: saving get objects to models

[Satinderpal Singh]

Thanks, for this help

On Tue, Jan 22, 2013 at 9:34 PM, Bill Freeman  wrote:
> Forgive me if I am not being direct, but I'm not sure I understand your
> question.
You understand the problem very well.

> For the python statement that you include in your question to work, the
> following must be true:
>
> 1. There must be a query parameter on the url named "material".  e.g.;
> http://localhost:8000/myview/?material=admantium
> (Usually this would be provided using a form html tag, plus an input or
> select tag with name='material'.)
I have query parameter "material" in the url.

> 2. There must not be multiple material query parameters named "material" (or
> only the last will be used).


> 3. There must already be a row in the database's table for the Material
> model whose name field matches the value of the query ("admantium" in the
> case of the url in point #1), and only one row with that name.  (The row
> will be fetched from the database, and the values of its fields will be used
> to initialize attributes of the python class instance called 'material' in
> your sample.)
Yes, there is a row present in the database whose name field matches
to the value of query.

> None of this is what is known as "save"ing in the context of Django.  "save"
> is the transfer of data from the python class instance back to the database.
> If this is truly what you wish to do, modifying your existing row, you
> would, after the  statement you provided, assign new values to one or more
> of instance's attributes (e.g.; material.color = 'pink'), and then call
> material.save().
This is the thing i am asking for, i am unable to save the context of
Django. I used the logic given by you but it did not worked. How will
i save the value of material in the database name field.

--
Satinderpal Singh
http://satindergoraya.blogspot.in/
http://satindergoraya91.blogspot.in/

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

Re: Struggling with slow startup / SQL in new app (using raw SQL)

[Nikolas Stevenson-Molnar]

Hi Matt,

It's unlikely the problem lies with dictfetchall. The "small performance hit" 
mentioned by the docs probably refers to the fact that the function has a time 
complexity of (number of colulmns) * (number of rows). Since you're only 
getting 10 rows back, I can't see that having an appreciable impact.

I haven't seen this kind of variation between performing a direct query, and 
executing the query as part of a Django request… especially with such a basic 
query. Do you see the same difference in timing locally or is it only when 
deployed?

_Nik

On Jan 22, 2013, at 4:47 AM, Matt Andrews  wrote:

> That looks really useful - for future reference, great! Sadly my webhost is 
> still bundling Django 1.2.3 :(
> 
> In general, though, these issues still come down to the fact that a SQL query 
> as executed by Django takes several times longer than going directly to the 
> DB. Is this down to my use of dictfetchall() or something more low level?
> 
> 
> On Tuesday, January 22, 2013 12:09:50 PM UTC, Jani Tiainen wrote:
> Hi, 
> 
> I see that you had quite a bunch of m2m keys. 
> 
> Have you tried recent version of Django (1.4+) with prefetch_related() [1] ? 
> 
> 
> [1] 
> 
>  
> 
> 
> 22.1.2013 13:57, Matt Andrews kirjoitti: 
> > Hi Jani, 
> > 
> > I made a StackOverflow post last year with an example of the ORM stuff I 
> > tried and the poor queries it produced: 
> > http://stackoverflow.com/questions/5843457/django-objects-all-making-360-queries-how-can-i-optimise-this-manytomany
> >  
> > 
> > There's also this discussion about how using the same queryset in two 
> > places in the template caused Django to request its data twice: 
> > http://stackoverflow.com/questions/9447053/best-way-to-slice-a-django-queryset-without-hitting-the-database-more-than-once
> >  (this 
> > was easily fixed, but again, not very intuitive and frustrated me) 
> > 
> > I don't have the data to hand currently but I also remember seeing weird 
> > things happen where queries would end with stuff like "... LIMIT 
> > 234423445" (or some crazy number which I'd never entered and was orders 
> > of magnitude bigger than the number of rows in the table). 
> > 
> > I'm aware these are probably edge cases that are down to my own novice 
> > status, but even using things like select_related(), it wasn't doing 
> > what I wanted. I just felt it easier to use my existing SQL (I'm 
> > converting a PHP app over to Django) and I'm not concerned about 
> > database portability (switching to postgres or whatever). 
> > 
> > Nik: just realised I missed your final question. For the SQL posted 
> > above, the numbers are approximately: 12,000 rows in the `news` table, 
> > maybe 10 `news_category` rows, about 100 `writers` and around 3000 
> > `images`. All properly indexed and with sensible column types. 
> > 
> > On Tuesday, January 22, 2013 10:53:40 AM UTC, Jani Tiainen wrote: 
> > 
> > Hi, 
> > 
> >   From your raw SQL I saw you're doing few joins. So I suppose you do 
> > quite a few foreign key fetches. 
> > 
> > You didn't mention anything how you originally tried to solve case with 
> > ORM. Could you please publish what you had when things were slow? 
> > 
> > 22.1.2013 12:26, Matt Andrews kirjoitti: 
> >  > Hi Nik, 
> >  > 
> >  > Thanks - I do feel like by circumventing the ORM I've just "given 
> > up" 
> >  > and perhaps I'll reconsider -- none of my queries are particularly 
> >  > "specialist" (as the sample above indicates) - I just found Django 
> >  > generating odd things. 
> >  > 
> >  > To answer your questions: 
> >  > 
> >  > 1. Yes, reloading the page sees the same time for the queries (it 
> > just 
> >  > feels as though the entire process takes a second or two to 
> > start, which 
> >  > is perhaps not related to SQL itself). 
> >  > 
> >  > 2. I believe so, yes (it's shared hosting...). 
> >  > 
> >  > If you're curious, you can see a sample of the app at 
> >  > http://beta.scenepointblank.com  
> > (obviously you won't see the SQL, but 
> >  > the "delay" between pages, even though these pages are all cached 
> > for 
> >  > 2hrs+, is partly my concern here). 
> >  > 
> >  > On Tuesday, January 22, 2013 4:24:09 AM UTC, Nikolas 
> > Stevenson-Molnar wrote: 
> >  > 
> >  > Hi Matt, 
> >  > 
> >  > Firstly, I encourage you to have another crack a the ORM. It can 
> >  > certainly seem a bit aggravating at times if you're coming 
> > from a 
> >  > SQL mindset, but really pays off down the road in terms of 
> >  > maintainability and readability. Typically you should only 
> > need raw 
> >  > queries in Django in cases where you have super-specialized 
> > (that 
> >  > uses 

Where can I put code that will get executed when page refreshes

[frocco]

I have a  index.html template that extends base.html
In Index I has:
{% block side_menu %}
Content
{% endblock %}

I fill this block from a database table.
This only works if I click on the home link.
if I click any other link to view, the side-menu is not populated.

url(r'^$', 'ntw.views.index', name='home'), works
url(r'^staff/', 'staff.views.index'), does not work

ntw.views.py has the code to query the database

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

What's the right pattern to re-use common view code?

[andrew jackson]

I have an object that shows up in lots of different parts of the system, 
say a Book.  

I want to display a list view of Book objects in many different places, 
e.g., 

When looking at an Author's detail page, I want to see a list of recent 
books they've written
when looking at a publisher page, similar.
In fact, even when looking at a book i'd like to have a list of books that 
reference it.

So, there's going to be html code that shows a table of books on several 
different pages.

My question is, what's the right way to follow DRY w/ django templates and 
not duplicate the code that makes a list of books?  

If I was using Jinja, it'd be pretty straightforward to {% include %} a 
snippet in each page that renders each queryset as a fancy table.  It 
doesn't look like template inheritance is set up that way here, though.

So what's the right way to do it with Django?  Am I thinking about it 
wrong?  I see a few django-fancy-tables plugins, but they seem pretty 
heavyweight, and i'd like to understand the right way to approach the 
solution here.  In fact, I don't even know the right words to use to 
describe the problem, so my google-fu is weak.  Do I write a custom 
template tag that takes a queryset as a parameter?  Aren't custom template 
tags to be avoided?


Thanks much for your time,
Andrew

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

Upload multiple files using Ajax

[Andre Lopes]

Hi,

I need to develop a form to upload multiple files.

I was thinking in using an Ajax uploader. I have google some options
but there are to many and I don't know which one to choose.

Any recommendations about this subject?


Best Regards,
André.

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

Re: saving get objects to models

[Bill Freeman]

Forgive me if I am not being direct, but I'm not sure I understand your
question.

For the python statement that you include in your question to work, the
following must be true:

1. There must be a query parameter on the url named "material".  e.g.;
http://localhost:8000/myview/?material=admantium
(Usually this would be provided using a form html tag, plus an input or
select tag with name='material'.)

2. There must not be multiple material query parameters named "material"
(or only the last will be used).

3. There must already be a row in the database's table for the Material
model whose name field matches the value of the query ("admantium" in the
case of the url in point #1), and only one row with that name.  (The row
will be fetched from the database, and the values of its fields will be
used to initialize attributes of the python class instance called
'material' in your sample.)

None of this is what is known as "save"ing in the context of Django.
"save" is the transfer of data from the python class instance back to the
database.  If this is truly what you wish to do, modifying your existing
row, you would, after the  statement you provided, assign new values to one
or more of instance's attributes (e.g.; material.color = 'pink'), and then
call material.save().

Bill

On Tue, Jan 22, 2013 at 10:09 AM, Satinderpal Singh <
satinder.goray...@gmail.com> wrote:

> How to save the objects to models without using form. I tried to save
> the name object to the model, but unable to do so,
>
> material = Material.objects.get(name=request.GET['material'])
>
> --
> Satinderpal Singh
> http://satindergoraya.blogspot.in/
> http://satindergoraya91.blogspot.in/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>

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

module object has not attribute JSONEncoder

[ghjim]

My root WSGI page is now throwing the error:

"AttributeError at /  module object has no attribute JSONEncoder"

I have seen several posts about this with implications that it might be a 
Python bug.  It started occurring  to me after I
did a number of system updates.  I have been unable to back out and get my 
web page working again 
(this will teach me to do better regression testing when I update my 
systems).

The error is thrown by 
/opt/django/Django-1.4.3/django/contrib/messages/storage/cookie.py.  There 
is a reference to
class MessageEncoder(json.JSONEncoder).

If I do a directory of json I see an attribute with this name:

python
>>>import json
>>>names=dir(json)
>>>print names

I am using Python2.7.3 which installs both json and simplejson.

If anybody has seen this I would appreciate some help.

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

Re: Global filtering of the querystes

[akaariai]

On 22 tammi, 08:32, Jani Tiainen  wrote:
> Hi,
>
> I've several models that share same attribute and form doing ajax
> queries to/from form in a browser window.
>
> For example owner:
>
> class MyClass(models.Model):
>      title = models.TextField(max_length=100)
>      owner = models.TextField(max_length=100)
>
> class MyOtherClass(models.Model):
>      title = models.TextField(max_length=100)
>      value = models.IntegerField()
>      owner = models.TextField(max_length=100)
>
> And so on.
>
> Now I would like to user have option in browser to filter any query
> based on model that has "owner" property to be filtered by owner.
>
> What is the best way to doit?
>
> I only could come up with threadlocals and special manager that can be
> fed with global filtering rules.

I think your solution is fine (even if it is uqly).

You could also try to avoid threadlocals and pass the data in
parameters. Sill, if you want you can likely play with DB views and do
the filtering in there using some session parameters and views. Other
than that I can't think of any obvious way to achieve what you want.

 - Anssi

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

Re: ignore field during form validation

[Sarfraz ahmad]

gusy i have form which has 5 fields i have defined a clean_field method
which doesn't allow a duplicate entry in the database.
bt when i tried to update the model instance while calling form.is_valid()
method it calls the clean_field() method and returns error that entry
already exists.


On Tue, Jan 22, 2013 at 2:57 AM, Mario Gudelj wrote:

> Add required=False to the form field and it won't be validated.
> On 22 Jan, 2013 2:30 AM, "Jonathan D. Baker" 
> wrote:
>
>>  Hi Sarfraz,
>>
>> If your form class inherits from ModelForm, you can use a subset of
>> fields within your form per the following documentation:
>> https://docs.djangoproject.com/en/dev/topics/forms/modelforms/#using-a-subset-of-fields-on-the-form
>>
>> If you're not inheriting from ModelForm, then it's a matter of
>> configuring your model and form fields to allow null/blank. In this case,
>> seeing your code would help provide more direction.
>>
>> Hope this helps,
>> Jonathan
>>
>> On 01/21/2013 04:34 AM, Sarfraz ahmad wrote:
>>
>> Hello everyone,
>>
>>  i m facing a problem while validating django
>> form. i have 5 form fields in a form and in the view i want to
>> validate only three form fields which i need to update .. tell me a
>> solution if anyone have any
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/django-users/-/oZfMAZ8FWt4J.
>> To post to this group, send email to django-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-users?hl=en.
>>
>>
>>
>> --
>> Software Developerhttps://github.com/jondbaker
>> GPG: 1F6F3FFD
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To post to this group, send email to django-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-users?hl=en.
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>

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

Re: want to update only a few fields of a form

[Sarfraz ahmad]

can you please give me an example of validating only three fields of a form
which have 5 fields

thanx guys

On Mon, Jan 21, 2013 at 7:17 PM, Babatunde Akinyanmi
wrote:

> Hi, this is well documented in the online documentation
> https://docs.djangoproject.com/en/dev/topics/forms/?from=olddocs
> https://docs.djangoproject.com/en/dev/ref/forms/validation/
>
> If you define the fields you want to with required=False, you shouldn't
> have issues
>
> Sent from my Windows Phone
> --
> From: Sarfraz ahmad
> Sent: 1/21/2013 1:59 PM
> To: django-users@googlegroups.com
> Subject: want to update only a few fields of a form
>
> i want to update only a few fields of a form bt not with the cleaned method
>
> i need to validate them in a view... please tell me a solution
> thenk you all
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/epxfcWcGCqUJ.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>

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

Re: Database Transaction

[Javier Guerra Giraldez]

On Mon, Jan 21, 2013 at 10:03 PM, Jian Chang  wrote:
> you can't do the transaction between two different databases.

i think the OP is talking about translation and not transaction.  as
in translating the data from an old representation to the new one.  a
better word might be migration.

of course, that's totally specific to his own code.  i don't think
there's much generic advise to give, beyond trying South's
datamigration facilities.  (which might not be the easiest way if the
representations are so different)


--
Javier

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

Re: Struggling with slow startup / SQL in new app (using raw SQL)

[Matt Andrews]

That looks really useful - for future reference, great! Sadly my webhost is 
still bundling Django 1.2.3 :(

In general, though, these issues still come down to the fact that a SQL 
query as executed by Django takes several times longer than going directly 
to the DB. Is this down to my use of dictfetchall() or something more low 
level?


On Tuesday, January 22, 2013 12:09:50 PM UTC, Jani Tiainen wrote:
>
> Hi, 
>
> I see that you had quite a bunch of m2m keys. 
>
> Have you tried recent version of Django (1.4+) with prefetch_related() [1] 
> ? 
>
>
> [1] 
> <
> https://docs.djangoproject.com/en/1.4/ref/models/querysets/#prefetch-related> 
>
>
>
> 22.1.2013 13:57, Matt Andrews kirjoitti: 
> > Hi Jani, 
> > 
> > I made a StackOverflow post last year with an example of the ORM stuff I 
> > tried and the poor queries it produced: 
> > 
> http://stackoverflow.com/questions/5843457/django-objects-all-making-360-queries-how-can-i-optimise-this-manytomany
>  
> > 
> > There's also this discussion about how using the same queryset in two 
> > places in the template caused Django to request its data twice: 
> > 
> http://stackoverflow.com/questions/9447053/best-way-to-slice-a-django-queryset-without-hitting-the-database-more-than-once(this
>  
> > was easily fixed, but again, not very intuitive and frustrated me) 
> > 
> > I don't have the data to hand currently but I also remember seeing weird 
> > things happen where queries would end with stuff like "... LIMIT 
> > 234423445" (or some crazy number which I'd never entered and was orders 
> > of magnitude bigger than the number of rows in the table). 
> > 
> > I'm aware these are probably edge cases that are down to my own novice 
> > status, but even using things like select_related(), it wasn't doing 
> > what I wanted. I just felt it easier to use my existing SQL (I'm 
> > converting a PHP app over to Django) and I'm not concerned about 
> > database portability (switching to postgres or whatever). 
> > 
> > Nik: just realised I missed your final question. For the SQL posted 
> > above, the numbers are approximately: 12,000 rows in the `news` table, 
> > maybe 10 `news_category` rows, about 100 `writers` and around 3000 
> > `images`. All properly indexed and with sensible column types. 
> > 
> > On Tuesday, January 22, 2013 10:53:40 AM UTC, Jani Tiainen wrote: 
> > 
> > Hi, 
> > 
> >   From your raw SQL I saw you're doing few joins. So I suppose you 
> do 
> > quite a few foreign key fetches. 
> > 
> > You didn't mention anything how you originally tried to solve case 
> with 
> > ORM. Could you please publish what you had when things were slow? 
> > 
> > 22.1.2013 12:26, Matt Andrews kirjoitti: 
> >  > Hi Nik, 
> >  > 
> >  > Thanks - I do feel like by circumventing the ORM I've just "given 
> > up" 
> >  > and perhaps I'll reconsider -- none of my queries are 
> particularly 
> >  > "specialist" (as the sample above indicates) - I just found 
> Django 
> >  > generating odd things. 
> >  > 
> >  > To answer your questions: 
> >  > 
> >  > 1. Yes, reloading the page sees the same time for the queries (it 
> > just 
> >  > feels as though the entire process takes a second or two to 
> > start, which 
> >  > is perhaps not related to SQL itself). 
> >  > 
> >  > 2. I believe so, yes (it's shared hosting...). 
> >  > 
> >  > If you're curious, you can see a sample of the app at 
> >  > http://beta.scenepointblank.com  
>
> > (obviously you won't see the SQL, but 
> >  > the "delay" between pages, even though these pages are all cached 
> > for 
> >  > 2hrs+, is partly my concern here). 
> >  > 
> >  > On Tuesday, January 22, 2013 4:24:09 AM UTC, Nikolas 
> > Stevenson-Molnar wrote: 
> >  > 
> >  > Hi Matt, 
> >  > 
> >  > Firstly, I encourage you to have another crack a the ORM. It 
> can 
> >  > certainly seem a bit aggravating at times if you're coming 
> > from a 
> >  > SQL mindset, but really pays off down the road in terms of 
> >  > maintainability and readability. Typically you should only 
> > need raw 
> >  > queries in Django in cases where you have super-specialized 
> > (that 
> >  > uses views or non-standard functions) queries or need some 
> > specific 
> >  > optimization. If there's really no way to perform many of 
> your 
> >  > "day-to-day" queries with the ORM then that's an indication 
> > that a 
> >  > different database design may fit your data model better. I 
> >  > understand that you may have a unique situation, but I just 
> > wanted 
> >  > to throw that out there as I personally find the ORM to be a 
> > huge 
> >  > time saver. 
> >  > 
> >  > Now, with that out of the way... a couple of considerations: 
> > 1) 

Re: Looking for a session cart

[frocco]

Thanks, I tried it last night and it seems like a fit for me, porting my 
PHP app logic.


On Monday, January 21, 2013 4:24:50 PM UTC-5, somecallitblues wrote:
>
> Use django-cart. It does store the cart content in db but it stores the 
> session as well, so it will nicely match the user to their cart content 
> according to the cart id stored inside a cookie. It's a breeze to implement 
> with any product model. I highly recommend it.
> On 22 Jan, 2013 7:43 AM, "frocco"  wrote:
>
>> Thanks, I need to look at this, not sure how django-cart knows what 
>> records are for each user logged in.
>>
>> On Monday, January 21, 2013 11:12:01 AM UTC-5, Stefano Probst wrote:
>>>
>>>
>>> But this is what 
>>> "sessions"does.
>>>  By default a session is saved in the database but you can move it 
>>> also in a cache (https://docs.djangoproject.**com/en/1.4/topics/http/**
>>> sessions/#using-cached-**sessions).
>>>  Memcached is realy performant.
>>> You can write by write "request.session['fav_color'] = green" and read 
>>> by write "request.session['fav_color']" or "fav_color = 
>>> request.session.get('fav_**color', 'red')" then "red" is the default 
>>> value if "fav_color" is'nt set.
>>> Am Montag, 21. Januar 2013 15:44:47 UTC+1 schrieb frocco:

 I found django-cart, but it seems to write to the database.
 I want to keep items in session until they checkout.

 Thanks for the link to Shop, I will take a look at that also.

 On Monday, January 21, 2013 8:54:00 AM UTC-5, Stefano Probst wrote:
>
> Did you mean something like 
> "sessions"(
> example
> )?
>
> Am Montag, 21. Januar 2013 13:50:13 UTC+1 schrieb frocco:
>>
>> Hello,
>>
>> I am learning django and want to port an app over from PHP.
>> In PHP, I use a session cart to store items purchased.
>> Is there anything for django?
>>
>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msg/django-users/-/-i0YYos4f3IJ.
>> To post to this group, send email to django...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to 
>> django-users...@googlegroups.com .
>> For more options, visit this group at 
>> http://groups.google.com/group/django-users?hl=en.
>>
>

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

Re: Struggling with slow startup / SQL in new app (using raw SQL)

[Jani Tiainen]

Hi,

I see that you had quite a bunch of m2m keys.

Have you tried recent version of Django (1.4+) with prefetch_related() [1] ?


[1] 




22.1.2013 13:57, Matt Andrews kirjoitti:

Hi Jani,

I made a StackOverflow post last year with an example of the ORM stuff I
tried and the poor queries it produced:
http://stackoverflow.com/questions/5843457/django-objects-all-making-360-queries-how-can-i-optimise-this-manytomany

There's also this discussion about how using the same queryset in two
places in the template caused Django to request its data twice:
http://stackoverflow.com/questions/9447053/best-way-to-slice-a-django-queryset-without-hitting-the-database-more-than-once
 (this
was easily fixed, but again, not very intuitive and frustrated me)

I don't have the data to hand currently but I also remember seeing weird
things happen where queries would end with stuff like "... LIMIT
234423445" (or some crazy number which I'd never entered and was orders
of magnitude bigger than the number of rows in the table).

I'm aware these are probably edge cases that are down to my own novice
status, but even using things like select_related(), it wasn't doing
what I wanted. I just felt it easier to use my existing SQL (I'm
converting a PHP app over to Django) and I'm not concerned about
database portability (switching to postgres or whatever).

Nik: just realised I missed your final question. For the SQL posted
above, the numbers are approximately: 12,000 rows in the `news` table,
maybe 10 `news_category` rows, about 100 `writers` and around 3000
`images`. All properly indexed and with sensible column types.

On Tuesday, January 22, 2013 10:53:40 AM UTC, Jani Tiainen wrote:

Hi,

  From your raw SQL I saw you're doing few joins. So I suppose you do
quite a few foreign key fetches.

You didn't mention anything how you originally tried to solve case with
ORM. Could you please publish what you had when things were slow?

22.1.2013 12:26, Matt Andrews kirjoitti:
 > Hi Nik,
 >
 > Thanks - I do feel like by circumventing the ORM I've just "given
up"
 > and perhaps I'll reconsider -- none of my queries are particularly
 > "specialist" (as the sample above indicates) - I just found Django
 > generating odd things.
 >
 > To answer your questions:
 >
 > 1. Yes, reloading the page sees the same time for the queries (it
just
 > feels as though the entire process takes a second or two to
start, which
 > is perhaps not related to SQL itself).
 >
 > 2. I believe so, yes (it's shared hosting...).
 >
 > If you're curious, you can see a sample of the app at
 > http://beta.scenepointblank.com 
(obviously you won't see the SQL, but
 > the "delay" between pages, even though these pages are all cached
for
 > 2hrs+, is partly my concern here).
 >
 > On Tuesday, January 22, 2013 4:24:09 AM UTC, Nikolas
Stevenson-Molnar wrote:
 >
 > Hi Matt,
 >
 > Firstly, I encourage you to have another crack a the ORM. It can
 > certainly seem a bit aggravating at times if you're coming
from a
 > SQL mindset, but really pays off down the road in terms of
 > maintainability and readability. Typically you should only
need raw
 > queries in Django in cases where you have super-specialized
(that
 > uses views or non-standard functions) queries or need some
specific
 > optimization. If there's really no way to perform many of your
 > "day-to-day" queries with the ORM then that's an indication
that a
 > different database design may fit your data model better. I
 > understand that you may have a unique situation, but I just
wanted
 > to throw that out there as I personally find the ORM to be a
huge
 > time saver.
 >
 > Now, with that out of the way... a couple of considerations:
1) you
 > say it's a slow "startup"; if you refresh the page do the
queries
 > run just as slow the second time around? and 2) are your
Django app
 > and phpMyAdmin running on the same machine? If not, could
transit
 > time be an issue?
 >
 > Finally, can you give an idea about the size of the tables in
 > question? How many rows in each?
 >
 > _Nik
 >
 > On 1/21/2013 3:25 PM, Matt Andrews wrote:
 >> Hi all,
 >>
 >> Fairly new to Django. I ended up pulling out all of the
 >> ORM-generated queries and writing my own SQL directly (I got
fed
 >> up trying to work out how to achieve the kind of things I
needed
 >> without Django adding in extra joins or unintended WHERE
clauses
 >> etc). All my app's SQL uses cursor.execute() and the
 >> 

Re: Struggling with slow startup / SQL in new app (using raw SQL)

[Matt Andrews]

Hi Jani,

I made a StackOverflow post last year with an example of the ORM stuff I 
tried and the poor queries it produced: 
http://stackoverflow.com/questions/5843457/django-objects-all-making-360-queries-how-can-i-optimise-this-manytomany

There's also this discussion about how using the same queryset in two 
places in the template caused Django to request its data twice: 
http://stackoverflow.com/questions/9447053/best-way-to-slice-a-django-queryset-without-hitting-the-database-more-than-once
 (this 
was easily fixed, but again, not very intuitive and frustrated me)

I don't have the data to hand currently but I also remember seeing weird 
things happen where queries would end with stuff like "... LIMIT 234423445" 
(or some crazy number which I'd never entered and was orders of magnitude 
bigger than the number of rows in the table).

I'm aware these are probably edge cases that are down to my own novice 
status, but even using things like select_related(), it wasn't doing what I 
wanted. I just felt it easier to use my existing SQL (I'm converting a PHP 
app over to Django) and I'm not concerned about database portability 
(switching to postgres or whatever). 

Nik: just realised I missed your final question. For the SQL posted above, 
the numbers are approximately: 12,000 rows in the `news` table, maybe 10 
`news_category` rows, about 100 `writers` and around 3000 `images`. All 
properly indexed and with sensible column types. 

On Tuesday, January 22, 2013 10:53:40 AM UTC, Jani Tiainen wrote:
>
> Hi, 
>
>  From your raw SQL I saw you're doing few joins. So I suppose you do 
> quite a few foreign key fetches. 
>
> You didn't mention anything how you originally tried to solve case with 
> ORM. Could you please publish what you had when things were slow? 
>
> 22.1.2013 12:26, Matt Andrews kirjoitti: 
> > Hi Nik, 
> > 
> > Thanks - I do feel like by circumventing the ORM I've just "given up" 
> > and perhaps I'll reconsider -- none of my queries are particularly 
> > "specialist" (as the sample above indicates) - I just found Django 
> > generating odd things. 
> > 
> > To answer your questions: 
> > 
> > 1. Yes, reloading the page sees the same time for the queries (it just 
> > feels as though the entire process takes a second or two to start, which 
> > is perhaps not related to SQL itself). 
> > 
> > 2. I believe so, yes (it's shared hosting...). 
> > 
> > If you're curious, you can see a sample of the app at 
> > http://beta.scenepointblank.com (obviously you won't see the SQL, but 
> > the "delay" between pages, even though these pages are all cached for 
> > 2hrs+, is partly my concern here). 
> > 
> > On Tuesday, January 22, 2013 4:24:09 AM UTC, Nikolas Stevenson-Molnar 
> wrote: 
> > 
> > Hi Matt, 
> > 
> > Firstly, I encourage you to have another crack a the ORM. It can 
> > certainly seem a bit aggravating at times if you're coming from a 
> > SQL mindset, but really pays off down the road in terms of 
> > maintainability and readability. Typically you should only need raw 
> > queries in Django in cases where you have super-specialized (that 
> > uses views or non-standard functions) queries or need some specific 
> > optimization. If there's really no way to perform many of your 
> > "day-to-day" queries with the ORM then that's an indication that a 
> > different database design may fit your data model better. I 
> > understand that you may have a unique situation, but I just wanted 
> > to throw that out there as I personally find the ORM to be a huge 
> > time saver. 
> > 
> > Now, with that out of the way... a couple of considerations: 1) you 
> > say it's a slow "startup"; if you refresh the page do the queries 
> > run just as slow the second time around? and 2) are your Django app 
> > and phpMyAdmin running on the same machine? If not, could transit 
> > time be an issue? 
> > 
> > Finally, can you give an idea about the size of the tables in 
> > question? How many rows in each? 
> > 
> > _Nik 
> > 
> > On 1/21/2013 3:25 PM, Matt Andrews wrote: 
> >> Hi all, 
> >> 
> >> Fairly new to Django. I ended up pulling out all of the 
> >> ORM-generated queries and writing my own SQL directly (I got fed 
> >> up trying to work out how to achieve the kind of things I needed 
> >> without Django adding in extra joins or unintended WHERE clauses 
> >> etc). All my app's SQL uses cursor.execute() and the 
> >> dictfetchall() method as referenced here 
> >> <
> https://docs.djangoproject.com/en/dev/topics/db/sql/#django.db.models.Manager.raw>.
>  
>
> >> 
> >> 
> >> I've found that my app incurs a couple of seconds load time in 
> >> production, with CPU time at 2532ms and overall time 4684ms 
> >> (according to the debug toolbar). I'm seeing 8 SQL queries take 
> >> 380ms, and each one seems to be several times slower when made by 
> >> Django versus 

Re: Struggling with slow startup / SQL in new app (using raw SQL)

[Jani Tiainen]

Hi,

From your raw SQL I saw you're doing few joins. So I suppose you do 
quite a few foreign key fetches.


You didn't mention anything how you originally tried to solve case with 
ORM. Could you please publish what you had when things were slow?


22.1.2013 12:26, Matt Andrews kirjoitti:

Hi Nik,

Thanks - I do feel like by circumventing the ORM I've just "given up"
and perhaps I'll reconsider -- none of my queries are particularly
"specialist" (as the sample above indicates) - I just found Django
generating odd things.

To answer your questions:

1. Yes, reloading the page sees the same time for the queries (it just
feels as though the entire process takes a second or two to start, which
is perhaps not related to SQL itself).

2. I believe so, yes (it's shared hosting...).

If you're curious, you can see a sample of the app at
http://beta.scenepointblank.com (obviously you won't see the SQL, but
the "delay" between pages, even though these pages are all cached for
2hrs+, is partly my concern here).

On Tuesday, January 22, 2013 4:24:09 AM UTC, Nikolas Stevenson-Molnar wrote:

Hi Matt,

Firstly, I encourage you to have another crack a the ORM. It can
certainly seem a bit aggravating at times if you're coming from a
SQL mindset, but really pays off down the road in terms of
maintainability and readability. Typically you should only need raw
queries in Django in cases where you have super-specialized (that
uses views or non-standard functions) queries or need some specific
optimization. If there's really no way to perform many of your
"day-to-day" queries with the ORM then that's an indication that a
different database design may fit your data model better. I
understand that you may have a unique situation, but I just wanted
to throw that out there as I personally find the ORM to be a huge
time saver.

Now, with that out of the way... a couple of considerations: 1) you
say it's a slow "startup"; if you refresh the page do the queries
run just as slow the second time around? and 2) are your Django app
and phpMyAdmin running on the same machine? If not, could transit
time be an issue?

Finally, can you give an idea about the size of the tables in
question? How many rows in each?

_Nik

On 1/21/2013 3:25 PM, Matt Andrews wrote:

Hi all,

Fairly new to Django. I ended up pulling out all of the
ORM-generated queries and writing my own SQL directly (I got fed
up trying to work out how to achieve the kind of things I needed
without Django adding in extra joins or unintended WHERE clauses
etc). All my app's SQL uses cursor.execute() and the
dictfetchall() method as referenced here

.


I've found that my app incurs a couple of seconds load time in
production, with CPU time at 2532ms and overall time 4684ms
(according to the debug toolbar). I'm seeing 8 SQL queries take
380ms, and each one seems to be several times slower when made by
Django versus hitting the database through phpMyAdmin or
something: eg, this query:

SELECT * FROM news
JOIN news_categories ON news.news_category_id =
news_categories.id 
LEFT JOIN writers ON news.writer_id = writers.id

LEFT JOIN images ON news.image_id = images.id 
ORDER BY news.is_sticky DESC, news.date_posted DESC
LIMIT 10


This takes 14.8ms when run in phpMyAdmin (against the production
database) but Django reports it as 85.2ms. The same ratios are
true for all my other queries.

All I can think of is the note on the dictfetchall() method in the
Django docs which describes a "small performance hit". Is this it?!

I've profiled the app too, although I'm a bit hazy about what it
all means. Here's a dump of the result:
http://pastebin.com/raw.php?i=UHE9edVC
 (this is from running on
my local server rather than production but performance is broadly
similar).

Can anyone help me? I realise I've perhaps gone off-piste by
writing raw SQL but I feel it was justified.

thanks,
Matt



--
Jani Tiainen

- Well planned is half done and a half done has been sufficient before...

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

Re: Struggling with slow startup / SQL in new app (using raw SQL)

[Matt Andrews]

Hi Nik,

Thanks - I do feel like by circumventing the ORM I've just "given up" and 
perhaps I'll reconsider -- none of my queries are particularly "specialist" 
(as the sample above indicates) - I just found Django generating odd things.

To answer your questions:

1. Yes, reloading the page sees the same time for the queries (it just 
feels as though the entire process takes a second or two to start, which is 
perhaps not related to SQL itself).

2. I believe so, yes (it's shared hosting...).

If you're curious, you can see a sample of the app at 
http://beta.scenepointblank.com (obviously you won't see the SQL, but the 
"delay" between pages, even though these pages are all cached for 2hrs+, is 
partly my concern here).

On Tuesday, January 22, 2013 4:24:09 AM UTC, Nikolas Stevenson-Molnar wrote:
>
>  Hi Matt,
>
> Firstly, I encourage you to have another crack a the ORM. It can certainly 
> seem a bit aggravating at times if you're coming from a SQL mindset, but 
> really pays off down the road in terms of maintainability and readability. 
> Typically you should only need raw queries in Django in cases where you 
> have super-specialized (that uses views or non-standard functions) queries 
> or need some specific optimization. If there's really no way to perform 
> many of your "day-to-day" queries with the ORM then that's an indication 
> that a different database design may fit your data model better. I 
> understand that you may have a unique situation, but I just wanted to throw 
> that out there as I personally find the ORM to be a huge time saver.
>
> Now, with that out of the way... a couple of considerations: 1) you say 
> it's a slow "startup"; if you refresh the page do the queries run just as 
> slow the second time around? and 2) are your Django app and phpMyAdmin 
> running on the same machine? If not, could transit time be an issue?
>
> Finally, can you give an idea about the size of the tables in question? 
> How many rows in each?
>
> _Nik
>
> On 1/21/2013 3:25 PM, Matt Andrews wrote:
>  
> Hi all, 
>
>  Fairly new to Django. I ended up pulling out all of the ORM-generated 
> queries and writing my own SQL directly (I got fed up trying to work out 
> how to achieve the kind of things I needed without Django adding in extra 
> joins or unintended WHERE clauses etc). All my app's SQL uses 
> cursor.execute() and the dictfetchall() method as referenced 
> here
> . 
>
>  I've found that my app incurs a couple of seconds load time in 
> production, with CPU time at 2532ms and overall time 4684ms (according to 
> the debug toolbar). I'm seeing 8 SQL queries take 380ms, and each one seems 
> to be several times slower when made by Django versus hitting the database 
> through phpMyAdmin or something: eg, this query:
>
>  SELECT * FROM news 
> JOIN news_categories ON news.news_category_id = news_categories.id 
> LEFT JOIN writers ON news.writer_id = writers.id 
> LEFT JOIN images ON news.image_id = images.id 
> ORDER BY news.is_sticky DESC, news.date_posted DESC 
> LIMIT 10
>
>
>  This takes 14.8ms when run in phpMyAdmin (against the production 
> database) but Django reports it as 85.2ms. The same ratios are true for all 
> my other queries.
>
>  All I can think of is the note on the dictfetchall() method in the 
> Django docs which describes a "small performance hit". Is this it?!
>
>  I've profiled the app too, although I'm a bit hazy about what it all 
> means. Here's a dump of the result: 
> http://pastebin.com/raw.php?i=UHE9edVC(this is from running on my local 
> server rather than production but 
> performance is broadly similar).
>
>  Can anyone help me? I realise I've perhaps gone off-piste by writing raw 
> SQL but I feel it was justified.
>
>  thanks,
> Matt
>
>  
>  -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To view this discussion on the web visit 
> https://groups.google.com/d/msg/django-users/-/Qiley9RqfngJ.
> To post to this group, send email to django...@googlegroups.com
> .
> To unsubscribe from this group, send email to 
> django-users...@googlegroups.com .
> For more options, visit this group at 
> http://groups.google.com/group/django-users?hl=en.
>
>
>  

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