Re: mod_python Error After mysqlhotcopy --help!!!
[EMAIL PROTECTED] wrote: > As for a I know, all I did was use mysqlhotcopy to backup some data and > now my whole site is down. > > Are there any issues with this? > > This site is supposed to go live in 24hrs. Wow, that sounds terrible -- I'm so sorry! There's nothing in Django that would cause this, so my immediate answer is that you should ask the mysql folks about it. If you can post more details about exactly what error messages your getting, someone here might know enough to help you out. Good luck, Jacob --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
mod_python Error After mysqlhotcopy --help!!!
Hi All, As for a I know, all I did was use mysqlhotcopy to backup some data and now my whole site is down. Are there any issues with this? This site is supposed to go live in 24hrs. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django versions
True, but I have found it forces me to look at django code more, which helps me learn it more. Guess its not for everyone. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Naming conventions in docs / tutorials
On Sat, Feb 25, 2006 at 06:18:20PM +, Luke Plant wrote: > 'Site' in that example was a model in my own app -- there is a Django > model of the same name, but I don't know that much about it. As I've been learning Django this past week, this type of naming issue has bitten me over and over and over. As a major change (magic-removal) is underway, now's the time to also go back through the documentation... I beg everyone doing documentation / tutorials to come up with some absolutely clear naming conventions -- that will make it crystal clear to people which substrings in a name are what. e.g. if I see "polls.Polls", which word is my app name or my module name or a model class name etc. There might have to be one "form" for documentation and another "form" for working code examples. e.g. for me, I find a string such as "/_get" to be crystal clear in documentation. Equally, I would find "APP_LABEL_MYPROJECT/MODULE_NAME_POLLS_get" to also work, but not be as crystal clear. -- Glenn Tenney --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django versions
On Fri, Feb 24, 2006 at 01:04:31PM -, ChaosKCW wrote: > So if your starting from scratch like > me, and your willilng to put up with a few bugs, the magic removal is > the way to go. The problem I see with the m-r path for a newbie is that all the docs, tutorials, and examples are pre-m-r ... so starting from scratch with the m-r means a lot more headaches in learning Django. -- Glenn Tenney --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: django problem at dreamhost
I have what I think is a similar problem - first time posting here so please, be gentle. I followed the instructions on the Django on Dreamhost wiki and correctly installed django. Everything seems to work fine... database tables are as expected... then I try to access mydomain.com/admin or mydomain.com/django.fcgi. After trying for several minutes, I get a 500: the error says "comm with (dynamic) server aborted" and "incomplete headers (0 bytes) received from server." However, when I run the sample hello.fcgi to verify that FastCGI is running, it works fine. Is there something wrong with the latest Django WSGI handler (I installed via svn) or is it something in my configuration that's causing this (to me) inexplicable error? Is this a Dreamhost only issue? Bryant Cutler bryantcutler.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Magic-removal roadmap?
On 2/25/06, Nicholas Matsakis <[EMAIL PROTECTED]> wrote: > > > Is there a (rough) timeframe set out for when the magic-removal branch > will be merged into the trunk? Will there be a Django release before that > which will incorporate all the improvements aside from the magic removal? > I'm not looking for exact dates, just where these events are likely to > happen in three months, six months, or longer. I'd guess that m-r will be merged to trunk before the end of March; there's a feeling that it's been branched for too long, and it's time to wrap things up. The Django sprint at PyCon this upcoming week should hopefully make serious inroads here. The next release should follow on the heels of the merge back; if you want the non-m-r features today, trunk is the place to be. :-) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Primary key with db_column set results in errors in admin
I posted a ticket about and a fix for this here: http://code.djangoproject.com/ticket/1394 In short, if you have a model whose primary key has the db_column option set to something other than the name of the attribute, the admin gets terribly confused (spits out a ProgrammingError) when you try to save it. I've looked through the code, and there are a couple places where it seems to assume the DB column and attribute name will never be different. This came up when I was subclassing auth.User, and replacing its primary key with a OneToOneField. Because I wanted to keep its interface the same as the original's (meaning, the same attribute names and db column names, since certain chunks of code rely on the normal names), I had to override the db_column option in the OneToOneField, which caused the admin to blow up, &c, &c. Anyway, the fixes (in the ticket) work just great. -Kirk McDonald --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Magic-removal roadmap?
Is there a (rough) timeframe set out for when the magic-removal branch will be merged into the trunk? Will there be a Django release before that which will incorporate all the improvements aside from the magic removal? I'm not looking for exact dates, just where these events are likely to happen in three months, six months, or longer. Nick Matsakis --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Enjoy this funny video
Take a moment to watch funny vidoe ofthe day at http://www.loltime.com. they have one new video everyday. So feel free to check it atleast once everyday. Also check out http://www.studentshangout.com ..a complete site with everything for you --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Help with Generic Views in Magic Removal Branch
Hi Thanks for your responses. Thats what I thought, just wanted to make sure. The all() just seems unitutive to me, but given that Djangos syntax is so easy, a little bit of something here and there is no biggie. Thanks again. PS I just posted a patch for the generic views on the developers list to add a template model name: http://code.djangoproject.com/ticket/1399 C --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: How to implement this fucntionality ? (current page higlighting)
If you don't want to set the section variable in your template context you can also do something similar by just defining a new block to contain your section id. Something like this: [...] etc... --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Help with Generic Views in Magic Removal Branch
On Saturday 25 February 2006 18:25, ChaosKCW wrote: > A dumb question, but will objects.all() cause any kind of performance > hit ? > > I mean when the code appends QuerySet.filter(pk=object_id), will it > condense that to a SQL statement that returns one object or reutrn > all obejcts then do the PK query ? It creates a new SQL statement that returns one objects, without ever having done the original query, so there is no performance hit. To do the PK query client side would mean you'd have to replicate all the features of the DB in Python. Luke -- Parenthetical remarks (however relevant) are unnecessary Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Help with Generic Views in Magic Removal Branch
A dumb question, but will objects.all() cause any kind of performance hit ? I mean when the code appends QuerySet.filter(pk=object_id), will it condense that to a SQL statement that returns one object or reutrn all obejcts then do the PK query ? Thanks, --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Help with Generic Views in Magic Removal Branch
On Saturday 25 February 2006 17:43, ChaosKCW wrote: > Just one question, I have used model.objects, not > model.objects.all(). It appears to work and makes more sense to me. > Any comments? Use model.objects.all() (at least for now). model.objects will work in some cases, but perhaps not in others. (Technically, it's to do with QuerySets caching their result for efficiency, and the fact that you don't want 'model.objects' to cache it's result). Luke -- Parenthetical remarks (however relevant) are unnecessary Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Help with Generic Views in Magic Removal Branch
On Saturday 25 February 2006 17:47, ChaosKCW wrote: > Hi > > Is there some documentation on the "Sites" functionality. I have seen > it, but not seen any docs ? 'Site' in that example was a model in my own app -- there is a Django model of the same name, but I don't know that much about it. Luke -- Parenthetical remarks (however relevant) are unnecessary Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Help with Generic Views in Magic Removal Branch
Hi Is there some documentation on the "Sites" functionality. I have seen it, but not seen any docs ? Thanks, --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Magic-Removal Branch Wiki Updated for generic view parameters
Hi I have updated the Magic Removal Branch Wiki with information on using Querysets and generic views. Thanks, C --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Help with Generic Views in Magic Removal Branch
Thanks, I had a look at the code and worked that out. Just one question, I have used model.objects, not model.objects.all(). It appears to work and makes more sense to me. Any comments? Thanks, Stephen --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Help with Generic Views in Magic Removal Branch
On Saturday 25 February 2006 16:58, ChaosKCW wrote:
> Please can someone help. I am following Tutorial4 for generic views,
> plus adapting it to the magic removal instructions on the wiki page.
> As far as I can tell i followed the instructions exactly, But I get
> an error stating that 'model' is not a valid paremeter to the view.
The tutorial is now badly out of date for magic-removal. Instead of
taking a model and app_label, they take a 'queryset' argument, which
should be a QuerySet object. QuerySet objects are what you implicitly
use in magic removal to do all lookups on the database. For instance,
Poll.objects.all() is a QuerySet. Because QuerySets are 'lazy', you
can create them in your URL conf and the data won't be retrieved at
that point, but each time the generic view is actually called. In my
urls.py I have something like this:
(r'^sites/$', 'list_detail.object_list',
{'queryset': Site.objects.all(),
'template_name': 'cciw/sites/index'
}
),
(r'^sites/(?P.*)/$', 'list_detail.object_detail',
{'queryset': Site.objects.all(),
'slug_field': 'slug_name',
'template_name': 'cciw/sites/detail'
}
),
...
Note how I use all the 'Site' objects in the both cases, but don't worry
-- only in the first case does it actually result in all the objects
being retrieved from the db, in the second case the view derives a new
QuerySet, based on the one passed in, that only gets a single object.
I personally think the new syntax is much nicer - no need for
'extra_lookup_args' etc. If you wanted to have a different ordering
plus extra filtering, you could change Site.objects.all() to e.g.
Site.objects.filter(visible=True).order_by('name').
One thing - I'm not sure all the generic views have been updated yet. I
do know the above examples work.
Luke
--
Parenthetical remarks (however relevant) are unnecessary
Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---
Re: ORDER BY on get_object?
As of revision 2392 in trunk, I've made this change. ORDER BY is no longer added for get_object() queries, unless you explicitly specify it. Thanks again for suggesting, Ned! Adrian --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: ORDER BY on get_object?
On Saturday 25 February 2006 14:33, Ned Batchelder wrote: > If I omit the ordered attribute, then there is no ORDER BY clause. > Surely the code that knows to omit the clause entirely in that case > could be triggered in the single-object case? I know, it's foolish to > ever guess at the structure of unknown code... You are right, it wouldn't be hard to change -- I was thinking about it in the wrong way. See Adrian's e-mail for an answer. Luke -- Parenthetical remarks (however relevant) are unnecessary Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Help with Generic Views in Magic Removal Branch
Hi
Please can someone help. I am following Tutorial4 for generic views,
plus adapting it to the magic removal instructions on the wiki page.
As far as I can tell i followed the instructions exactly, But I get an
error stating that 'model' is not a valid paremeter to the view.
I am sure its somthing dumb I have done, but if anyone spots it I would
appreciate some help. I have pasted the ERROR and the urls.py below
(cant see an attach file option in GG).
Thanks in Advance,
S
** ERROR
TypeError at /surveys/survey/1/
object_detail() got an unexpected keyword argument 'model'
Request Method: GET
Request URL:http://127.0.0.1:8000/surveys/survey/1/
Exception Type: TypeError
Exception Value:object_detail() got an unexpected keyword argument
'model'
Exception Location:
H:\Programming\Python\Python24\lib\site-packages\django\core\handlers\base.py
in get_response, line 72
Traceback (innermost last)
*
H:\Programming\Python\Python24\lib\site-packages\django\core\handlers\base.py
in get_response
65. # Apply view middleware
66. for middleware_method in self._view_middleware:
67. response = middleware_method(request, callback,
callback_args, callback_kwargs)
68. if response:
69. return response
70.
71. try:
72. response = callback(request, *callback_args,
**callback_kwargs) ...
73. except Exception, e:
74. # If the view raised an exception, run it through exception
75. # middleware, and if the exception middleware returns a
76. # response, use that. Otherwise, reraise the exception.
77. for middleware_method in self._exception_middleware:
78. response = middleware_method(request, e)
▶ Local vars
*** URL ***
from django.conf.urls.defaults import *
from bard.survey.models import Survey
info_dict = {'model': Survey}
urlpatterns = patterns('',
(r'^$', 'bard.survey.views.index'),
#(r'^survey/(?P\d+)/$',
'django.views.generic.list_detail.object_detail')
(r'^survey/(?P\d+)/$',
'django.views.generic.list_detail.object_detail', info_dict)
)
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---
Re: ORDER BY on get_object?
On 2/25/06, Ned Batchelder <[EMAIL PROTECTED]> wrote: > If I specify an 'ordering' attribute in my model's META class, it gets > used even for single-object selects, for example, get_object. > > So there are SQL queries like this: > > SELECT field, field FROM app_model WHERE id = 50 ORDER BY date DESC > > Surely the ORDER BY clause can be omitted? Is the magic-removal branch > already fixing this? Thanks for pointing this out. You can remove the ORDER BY clause entirely by passing an empty tuple or list as the order_by argument to get_object(): someapp.get_object(pk=50, order_by=()) But that's a pretty lame hack. It would be easy to change the behavior for get_object() so that it doesn't use the ordering clause from the model. My only hesitation is that it would slightly change the meaning of get_object(), because some people might be using, for example, get_object(limit=1), relying on the fact that get_object() would be using the model's ordering. However, I think this is an acceptable change, as long as we document the change on the backwards-incompatible changes page. Any objections before I check in that change to trunk? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com | chicagocrime.org --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Template IF statement with <,>,<=,>= (or equvalent)
[EMAIL PROTECTED] wrote: >Django Template engine seems to be very strate forward yet powerful, >however I can't for the life of me figure out how to check if variable1 >is greater then or smaller then variable2. > > You can't. Django's philosophy is that this is logic is probably a small part of some buisness logic decision and should be done at view level. For less vague answer describe the whole problem: what exactly are you trying to solve with this check? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Template
It would be easier to give advice if we could see the whole story and
not only details. Could you express in clear terms what you are trying
to achieve?
But to get started:
To test if page.title == "menu":
{% ifequal page.title "menu" %} {% endifequal %}
To retrieve objects from the database, you could write a custom
template tag. But to keep things clear, it's best to retrieve and
prepare data already in the view, unless there's a really good reason
to do it at the template level.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---
Re: ORDER BY on get_object?
No, I'm sure the database is not slowed by this. There's only a single record, so even if it bothered to "sort" it, it would sort quickly. But it seems sloppy, and feeds into fears about ORMs not being able to do SQL efficiently enough for serious systems. If I omit the ordered attribute, then there is no ORDER BY clause. Surely the code that knows to omit the clause entirely in that case could be triggered in the single-object case? I know, it's foolish to ever guess at the structure of unknown code... --Ned. Luke Plant wrote: On Saturday 25 February 2006 14:07, Ned Batchelder wrote: So there are SQL queries like this: SELECT field, field FROM app_model WHERE id = 50 ORDER BY date DESC Surely the ORDER BY clause can be omitted? Is the magic-removal branch already fixing this? Yep, the order by clause could be omitted. However, in magic-removal (and I guess on trunk) the same mechanism is used to get single objects and multiple objects - for single objects you just filter on the value of the primary key. So removing the ORDER BY would be more trouble than it's worth - you would have to add a special case for it (and the code to check for it might not be completely trivial), and it wouldn't have any effect on the results. I can't imagine it would have much effect on performance either, but I don't know much about DB optimisation. If you can show that it does affect performance on a popular DB then there would some motivation to change this. Regards, Luke -- Ned Batchelder, http://nedbatchelder.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: ORDER BY on get_object?
On Saturday 25 February 2006 14:07, Ned Batchelder wrote: > So there are SQL queries like this: > > SELECT field, field FROM app_model WHERE id = 50 ORDER BY date DESC > > Surely the ORDER BY clause can be omitted? Is the magic-removal > branch already fixing this? Yep, the order by clause could be omitted. However, in magic-removal (and I guess on trunk) the same mechanism is used to get single objects and multiple objects - for single objects you just filter on the value of the primary key. So removing the ORDER BY would be more trouble than it's worth - you would have to add a special case for it (and the code to check for it might not be completely trivial), and it wouldn't have any effect on the results. I can't imagine it would have much effect on performance either, but I don't know much about DB optimisation. If you can show that it does affect performance on a popular DB then there would some motivation to change this. Regards, Luke -- Parenthetical remarks (however relevant) are unnecessary Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
ORDER BY on get_object?
If I specify an 'ordering' attribute in my model's META class, it gets used even for single-object selects, for example, get_object. So there are SQL queries like this: SELECT field, field FROM app_model WHERE id = 50 ORDER BY date DESC Surely the ORDER BY clause can be omitted? Is the magic-removal branch already fixing this? -- Ned Batchelder, http://nedbatchelder.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Django versions
On Saturday 25 Feb 2006 6:44 am, oggie rob wrote: > If you plan to deploy anytime in the next month or two (yes, this > is a real possibility with Django!), month or two? you mean there are people out there who take up to a *month* to deploy a django app?? -- regards kg http://www.livejournal.com/users/lawgon tally ho! http://avsap.org.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Template
i need to say in the template this but i don't know how: i want to say if page.title =menu so the output will be page.content as i need to retreive from the database the content of the page that has title called menu and this is in my template can anyone help --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: Web Services
Thanks for the all the posts, I will look into them all thouraghly. Might take some time as this is a sapre time project :-) Thanks again, S --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: edit_inline & raw_id_admin
the code i posted was fine. i just had to restart the server. patrick > > On Fri, 2006-02-24 at 15:43 +0100, va:patrick.kranzlmueller wrote: >> first think, then write -> problem solved! > > Since you are unlikely to be the only person to ever come across this > problem, how about posting your solution to the list so that it shows up > in a search of the archives? > > Thanks, > Malcolm > > > > --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
