WEB SERVICE

[sami nathan]

Hi
  i want to do web service in using django  My client is sending SOAP
request and should send response as SOAP response i am now sucessful in this
process using ZSI but i want to run the process in django server So i
refered http://djangosnippets.org/snippets/979/ now it would be helpfull for
me if i get help of running echo server  using the same example

-- 
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: how to remove add and change links on admin dashboard

[Derek]

In the docs:
http://docs.djangoproject.com/en/dev/ref/contrib/admin/#overriding-admin-templates

Also helpful:
http://www.ibm.com/developerworks/opensource/library/os-django-admin/index.html


On Jan 24, 6:53 am, Subhranath Chunder  wrote:
> Override the templates.
>
> On 23 Jan 2011 07:12, "rahul jain"  wrote:
>
> Hi Guys,
>
> how to remove add and change links + icons on admin dashboard ?
>
> Thanks.
>
> Rahul
>
>  --
> 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 
> athttp://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: Pinax: worth installing?

[Derek]

James

I know that asking "when" for delivery of an open source project is
not usually a question that can be answered accurately, but would it
be possible for you to give at least a broad estimation of which of
the following is closest to a time-frame for the next release that
includes an updated-and-production-ready (foundational)
social_project:
a) next few weeks
b) next few months
c) maybe sometime in 2011

Thanks
Derek

On Jan 23, 1:21 am, James Tauber  wrote:
> On Jan 18, 2011, at 9:32 AM, Russell Keith-Magee wrote:
>
>
>
> > I think we need to clear up some misconceptions here.
> [...]
> > Pinax, on the other hand, works at a higher level. Pinax targets a
> > specific domain -- social web apps
>
> Actually, this is a major misconception. Pinax is not targeting a specific 
> domain. And in fact, the social features are probably those features of Pinax 
> least production-ready. Sites like eldarion.com, us.pycon.org, 
> pinaxproject.com, gondor.io and quisition.com are all examples of Pinax that 
> have nothing particularly "social" about them.
>
> > So - you really don't have to make a "Pinax or Django" decision. Any
> > app that can be installed in a Django site can also be installed in a
> > Pinax site, and every Pinax site is a Django site.
>
> Exactly.
>
> > As for the original question -- are there any drawbacks? Well, not
> > really. Pinax suggests a particular collection of apps, but you can
> > use any other app you want in parallel. Pinax mandates a few standards
> > for project layout and the like, but for the most part, they're just
> > using the best practices commonly understood by experienced members of
> > the Django community, but the Django project itself hasn't gone to the
> > trouble of formalizing.
>
> Yep. And it's important to note you can use Pinax *just* for this. The 
> zero_project is appropriate for almost any kind of django site and, for the 
> most common type of account management, account_project is a good starting 
> point.
>
> > About the only potential downside I can see is that If you're not
> > building something in Pinax's sweet spot -- i.e., a social web site --
> > you won't get all the benefits that Pinax has to offer. If you're
> > building something *really* different, you might find that Pinax's
> > conventions obstruct you in ways that a raw Django install wouldn't.
> > However, for most "websitey" websites, this won't be an issue --
> > Pinax's conventions are, for the most part, a bunch of practices that
> > you should probably be following anyway -- Pinax just forces/provides
> > the tools to help you to follow them :-)
>
> The social stuff is in many ways Pinax's current weakness. It's the social 
> stuff that hasn't been updated for our next release yet (although we're 
> working towards it)
>
> I was planning on doing this anyway, but this thread has encouraged me even 
> more than I need to write some blog posts about things like Pinax's 
> zero_project, static_project and account_project in the coming weeks.
>
> James

-- 
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 - Verfication of runserver vs browser

[Shawn Milochik]

If you've been messing around quite a bit trying to fix other issues, the port 
may be held up by a zombie process or something. 

Try rebooting. If that doesn't work, see if the command line where runserver is 
running displays any message. 

Shawn

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

Django - Verfication of runserver vs browser

[Kimberly]

I ran the server by typing in the command: python manage.py runserver
and there's ( 0 errors) but when I check the browser by placing the
given url address:  http://127.0.0.1:8000/, it says it refused the
connection. It said that the server may be busy or may have network
connection problem. It also said I may have an old version of the page
I wanted

1) Google cache
2) Internet Archive

So, this is a problem with the internet connection obviously, but
should I make changes to the cache or at least update the page? I
followed the wiki example given on the Django site.

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

[Kimberly Harvey]

Thanks for the advice. Thanks for your help!

On Mon, Jan 24, 2011 at 12:10 AM, Graham Dumpleton <
graham.dumple...@gmail.com> wrote:

>
> our help
> On Monday, January 24, 2011 5:05:05 PM UTC+11, Kimberly wrote:
>>
>> LOL, I do have another thing I want to ask. I ran the server ( 0 errors)
>> but when to the browser to check,  http://127.0.0.1:8000/ and now it says
>> it refused the connection. It said that the server may be busy or may have
>> network connection problem. It also said I may have an old version of the
>> page I wanted
>> 1) Google cache
>> 2) Internet Archive
>>
>
> If you have a new problem and can't work out out, I would strongly suggest
> you create a new distinct message thread so that it isn't buried in this
> one. This one has gone on so long that people would now be ignoring it most
> likely. Use a new thread for new issue and you will have more luck getting
> help with it. More than likely your issue is transient and will resolve
> itself. Am sure someone else will help if they are able. I am taking a break
> for a while.
>
> Graham
>
>
>> Please tell me that it has nothing to do with the settings, manage, urls,
>> etc files. Do I need to change my cache as it may be the problem?
>>
>> As for the question about the settings.py, and settings.py.broken, I won't
>> question it, lol.
>>
>> On Sun, Jan 23, 2011 at 11:50 PM, Graham Dumpleton > > wrote:
>>
>>>
>>>
>>> On Monday, January 24, 2011 4:39:47 PM UTC+11, Kimberly wrote:

 Screen:

 You just installed Django's auth system, which means you don't have any
 superusers defined.

 So it is working

 I do have a question... after I've used the move technique to move the
 settings.py settings.py.broken which places all of the file of settings.py
 inside the settings.py.broken. I then MOVED the file again from
 settings.py.broken to settings.py and at the command line, python manage.py
 syncdb it works! May I ask why it worked like that?

>>>
>>> No idea. Just don't put any backup copy of settings.py in the directory
>>> above where the proper one is located. This is because Django does a trick
>>> with the Python module search path so that that parent directory gets added
>>> to sys.path for a moment and this may cause that backup copy to get imported
>>> wrongly meaning wrong settings used. So, don't question it, just be happy it
>>> is working. :-)
>>>
>>> Graham
>>>
>>>
>>>
 On Sun, Jan 23, 2011 at 11:32 PM, Graham Dumpleton 
 wrote:

>
>
> On Monday, January 24, 2011 4:25:52 PM UTC+11, Kimberly wrote:
>>
>> The directory I did it from was from my home directory. I've moved the
>> files like you've indicated by using mv settings.py settings.py.broken.
>>
>> Should I go ahead and type in the command as python manage.py syncdb
>> to see if it works?
>>
>
> YES. YES. YES.
>
> :-)
>
> Graham
>
>
>
>>
>> On Sun, Jan 23, 2011 at 11:17 PM, Graham Dumpleton > > wrote:
>>
>>>
>>>
>>> On Monday, January 24, 2011 4:10:15 PM UTC+11, Kimberly wrote:


   /home/username/wikicamp/wikicamp/settings.py -->  THIS DOES NOT
 EXIST

 WHAT DOES EXIST: /home/username/wikicamp and inside that directory,
 settings.py is there.

>>>
>>> Earlier you said you got:
>>>
>>>   import settings
>>>   print settings.__file__
>>>
>>>   import wikicamp.settings
>>>   print wikicamp.settings.__file__
>>>
>>>   after importing setting
>>>   print settings.__file__
>>>   OUTPUT: settings.pyc
>>>
>>>   import wikicamp.settings
>>>   print wikicamp.settings.__file__
>>>
>>>   OUTPUT: wikicamp/settings.pyc
>>>
>>> What directory did you do that from.
>>>
>>> If you didn't run this from inside of site directory as was expecting
>>> and you did it from your home directory, then you have a settings.py 
>>> sitting
>>> in your home directory which is the problem. Rename any settings.py 
>>> file you
>>> home directory to something else.
>>>
>>>   mv ~/settings.py ~/settings.py.broken
>>>
>>> In short, you have more than one settings.py file somewhere where it
>>> is being found and the second one is causing a conflict.
>>>
>>> Graham
>>>
>>>
  On Sun, Jan 23, 2011 at 11:02 PM, Kimberly Harvey <
 kha...@gmail.com> wrote:

>   Sorry about that, there is nothing showing for either  echo
> $PYTHONPATH and  echo $DJANGO_SETTINGS_MODULE
>
> I am currently reading your messages.
>
>
>  On Sun, Jan 23, 2011 at 10:55 PM, Graham Dumpleton <
> gra...@gmail.com> wrote:
>
>>
>>
>> On Monday, January 24, 2011 3:44:59 PM UTC+11, Kimberly wrote:
>>>
>>> Please do the following and pro

Re: Django Improper Configuration

[Graham Dumpleton]

On Monday, January 24, 2011 5:05:05 PM UTC+11, Kimberly wrote:
>
> LOL, I do have another thing I want to ask. I ran the server ( 0 errors) 
> but when to the browser to check,  http://127.0.0.1:8000/ and now it says 
> it refused the connection. It said that the server may be busy or may have 
> network connection problem. It also said I may have an old version of the 
> page I wanted
> 1) Google cache
> 2) Internet Archive
>

If you have a new problem and can't work out out, I would strongly suggest 
you create a new distinct message thread so that it isn't buried in this 
one. This one has gone on so long that people would now be ignoring it most 
likely. Use a new thread for new issue and you will have more luck getting 
help with it. More than likely your issue is transient and will resolve 
itself. Am sure someone else will help if they are able. I am taking a break 
for a while.

Graham
 

> Please tell me that it has nothing to do with the settings, manage, urls, 
> etc files. Do I need to change my cache as it may be the problem? 
>
> As for the question about the settings.py, and settings.py.broken, I won't 
> question it, lol.
>
> On Sun, Jan 23, 2011 at 11:50 PM, Graham Dumpleton 
> wrote:
>
>>
>>
>> On Monday, January 24, 2011 4:39:47 PM UTC+11, Kimberly wrote:
>>>
>>> Screen:
>>>
>>> You just installed Django's auth system, which means you don't have any 
>>> superusers defined.
>>>
>>> So it is working
>>>
>>> I do have a question... after I've used the move technique to move the 
>>> settings.py settings.py.broken which places all of the file of settings.py 
>>> inside the settings.py.broken. I then MOVED the file again from 
>>> settings.py.broken to settings.py and at the command line, python manage.py 
>>> syncdb it works! May I ask why it worked like that?
>>>
>>
>> No idea. Just don't put any backup copy of settings.py in the directory 
>> above where the proper one is located. This is because Django does a trick 
>> with the Python module search path so that that parent directory gets added 
>> to sys.path for a moment and this may cause that backup copy to get imported 
>> wrongly meaning wrong settings used. So, don't question it, just be happy it 
>> is working. :-)
>>
>> Graham
>>
>>  
>>
>>> On Sun, Jan 23, 2011 at 11:32 PM, Graham Dumpleton 
>>> wrote:
>>>
  

 On Monday, January 24, 2011 4:25:52 PM UTC+11, Kimberly wrote:
>
> The directory I did it from was from my home directory. I've moved the 
> files like you've indicated by using mv settings.py settings.py.broken.
>
> Should I go ahead and type in the command as python manage.py syncdb to 
> see if it works? 
>

 YES. YES. YES.

 :-)

 Graham

  

>
> On Sun, Jan 23, 2011 at 11:17 PM, Graham Dumpleton 
> wrote:
>
>>  
>>
>> On Monday, January 24, 2011 4:10:15 PM UTC+11, Kimberly wrote:
>>>
>>>
>>>   /home/username/wikicamp/wikicamp/settings.py -->  THIS DOES NOT 
>>> EXIST
>>>
>>> WHAT DOES EXIST: /home/username/wikicamp and inside that directory, 
>>> settings.py is there.
>>>
>>
>> Earlier you said you got:
>>
>>   import settings
>>   print settings.__file__
>>
>>   import wikicamp.settings
>>   print wikicamp.settings.__file__
>>
>>   after importing setting
>>   print settings.__file__
>>   OUTPUT: settings.pyc
>>
>>   import wikicamp.settings
>>   print wikicamp.settings.__file__
>>
>>   OUTPUT: wikicamp/settings.pyc
>>
>> What directory did you do that from.
>>
>> If you didn't run this from inside of site directory as was expecting 
>> and you did it from your home directory, then you have a settings.py 
>> sitting 
>> in your home directory which is the problem. Rename any settings.py file 
>> you 
>> home directory to something else.
>>
>>   mv ~/settings.py ~/settings.py.broken
>>
>> In short, you have more than one settings.py file somewhere where it 
>> is being found and the second one is causing a conflict.
>>
>> Graham
>>  
>>
>>>  On Sun, Jan 23, 2011 at 11:02 PM, Kimberly Harvey >> > wrote:
>>>
   Sorry about that, there is nothing showing for either  echo 
 $PYTHONPATH and  echo $DJANGO_SETTINGS_MODULE

 I am currently reading your messages.


  On Sun, Jan 23, 2011 at 10:55 PM, Graham Dumpleton <
 gra...@gmail.com> wrote:

>
>
> On Monday, January 24, 2011 3:44:59 PM UTC+11, Kimberly wrote:
>>
>> Please do the following and provide the output:
>>
>>   pwd
>>
>> MY OUTPUT: /home/username/wikicamp
>>
>> Now run 'python' from the command line and do the following, 
>> providing the output to us:
>>
>>   import settings
>>   p

Re: Django Improper Configuration

[Kimberly Harvey]

LOL, I do have another thing I want to ask. I ran the server ( 0 errors) but
when to the browser to check,  http://127.0.0.1:8000/ and now it says it
refused the connection. It said that the server may be busy or may have
network connection problem. It also said I may have an old version of the
page I wanted
1) Google cache
2) Internet Archive

Please tell me that it has nothing to do with the settings, manage, urls,
etc files. Do I need to change my cache as it may be the problem?

As for the question about the settings.py, and settings.py.broken, I won't
question it, lol.

On Sun, Jan 23, 2011 at 11:50 PM, Graham Dumpleton <
graham.dumple...@gmail.com> wrote:

>
>
> On Monday, January 24, 2011 4:39:47 PM UTC+11, Kimberly wrote:
>>
>> Screen:
>>
>> You just installed Django's auth system, which means you don't have any
>> superusers defined.
>>
>> So it is working
>>
>> I do have a question... after I've used the move technique to move the
>> settings.py settings.py.broken which places all of the file of settings.py
>> inside the settings.py.broken. I then MOVED the file again from
>> settings.py.broken to settings.py and at the command line, python manage.py
>> syncdb it works! May I ask why it worked like that?
>>
>
> No idea. Just don't put any backup copy of settings.py in the directory
> above where the proper one is located. This is because Django does a trick
> with the Python module search path so that that parent directory gets added
> to sys.path for a moment and this may cause that backup copy to get imported
> wrongly meaning wrong settings used. So, don't question it, just be happy it
> is working. :-)
>
> Graham
>
>
>
>> On Sun, Jan 23, 2011 at 11:32 PM, Graham Dumpleton > > wrote:
>>
>>>
>>>
>>> On Monday, January 24, 2011 4:25:52 PM UTC+11, Kimberly wrote:

 The directory I did it from was from my home directory. I've moved the
 files like you've indicated by using mv settings.py settings.py.broken.

 Should I go ahead and type in the command as python manage.py syncdb to
 see if it works?

>>>
>>> YES. YES. YES.
>>>
>>> :-)
>>>
>>> Graham
>>>
>>>
>>>

 On Sun, Jan 23, 2011 at 11:17 PM, Graham Dumpleton 
 wrote:

>
>
> On Monday, January 24, 2011 4:10:15 PM UTC+11, Kimberly wrote:
>>
>>
>>   /home/username/wikicamp/wikicamp/settings.py -->  THIS DOES NOT
>> EXIST
>>
>> WHAT DOES EXIST: /home/username/wikicamp and inside that directory,
>> settings.py is there.
>>
>
> Earlier you said you got:
>
>   import settings
>   print settings.__file__
>
>   import wikicamp.settings
>   print wikicamp.settings.__file__
>
>   after importing setting
>   print settings.__file__
>   OUTPUT: settings.pyc
>
>   import wikicamp.settings
>   print wikicamp.settings.__file__
>
>   OUTPUT: wikicamp/settings.pyc
>
> What directory did you do that from.
>
> If you didn't run this from inside of site directory as was expecting
> and you did it from your home directory, then you have a settings.py 
> sitting
> in your home directory which is the problem. Rename any settings.py file 
> you
> home directory to something else.
>
>   mv ~/settings.py ~/settings.py.broken
>
> In short, you have more than one settings.py file somewhere where it is
> being found and the second one is causing a conflict.
>
> Graham
>
>
>>  On Sun, Jan 23, 2011 at 11:02 PM, Kimberly Harvey 
>> wrote:
>>
>>>  Sorry about that, there is nothing showing for either  echo
>>> $PYTHONPATH and  echo $DJANGO_SETTINGS_MODULE
>>>
>>> I am currently reading your messages.
>>>
>>>
>>>  On Sun, Jan 23, 2011 at 10:55 PM, Graham Dumpleton <
>>> grah...@gmail.com> wrote:
>>>


 On Monday, January 24, 2011 3:44:59 PM UTC+11, Kimberly wrote:
>
> Please do the following and provide the output:
>
>   pwd
>
> MY OUTPUT: /home/username/wikicamp
>
> Now run 'python' from the command line and do the following,
> providing the output to us:
>
>   import settings
>   print settings.__file__
>
>   import wikicamp.settings
>   print wikicamp.settings.__file__
>
> after importing setting
> print settings.__file__
> OUTPUT: settings.pyc
>
>  import wikicamp.settings
>   print wikicamp.settings.__file__
>
> OUTPUT: wikicamp/settings.pyc
>

 Unfortunately you did not show what PYTHONPATH, or
 DJANGO_SETTINGS_MODULE was set to in environment to eliminate them as 
 cause,
 but the above suggests that you have two Django projects created. One 
 is at:

   /home/username/wikicamp

 and the other a

Re: Django Improper Configuration

[Graham Dumpleton]

On Monday, January 24, 2011 4:39:47 PM UTC+11, Kimberly wrote:
>
> Screen:
>
> You just installed Django's auth system, which means you don't have any 
> superusers defined.
>
> So it is working
>
> I do have a question... after I've used the move technique to move the 
> settings.py settings.py.broken which places all of the file of settings.py 
> inside the settings.py.broken. I then MOVED the file again from 
> settings.py.broken to settings.py and at the command line, python manage.py 
> syncdb it works! May I ask why it worked like that?
>

No idea. Just don't put any backup copy of settings.py in the directory 
above where the proper one is located. This is because Django does a trick 
with the Python module search path so that that parent directory gets added 
to sys.path for a moment and this may cause that backup copy to get imported 
wrongly meaning wrong settings used. So, don't question it, just be happy it 
is working. :-)

Graham

 

> On Sun, Jan 23, 2011 at 11:32 PM, Graham Dumpleton 
> wrote:
>
>>
>>
>> On Monday, January 24, 2011 4:25:52 PM UTC+11, Kimberly wrote:
>>>
>>> The directory I did it from was from my home directory. I've moved the 
>>> files like you've indicated by using mv settings.py settings.py.broken.
>>>
>>> Should I go ahead and type in the command as python manage.py syncdb to 
>>> see if it works? 
>>>
>>
>> YES. YES. YES.
>>
>> :-)
>>
>> Graham
>>
>>  
>>
>>>
>>> On Sun, Jan 23, 2011 at 11:17 PM, Graham Dumpleton 
>>> wrote:
>>>
  

 On Monday, January 24, 2011 4:10:15 PM UTC+11, Kimberly wrote:
>
>
>   /home/username/wikicamp/wikicamp/settings.py -->  THIS DOES NOT EXIST
>
> WHAT DOES EXIST: /home/username/wikicamp and inside that directory, 
> settings.py is there.
>

 Earlier you said you got:

   import settings
   print settings.__file__

   import wikicamp.settings
   print wikicamp.settings.__file__

   after importing setting
   print settings.__file__
   OUTPUT: settings.pyc

   import wikicamp.settings
   print wikicamp.settings.__file__

   OUTPUT: wikicamp/settings.pyc

 What directory did you do that from.

 If you didn't run this from inside of site directory as was expecting 
 and you did it from your home directory, then you have a settings.py 
 sitting 
 in your home directory which is the problem. Rename any settings.py file 
 you 
 home directory to something else.

   mv ~/settings.py ~/settings.py.broken

 In short, you have more than one settings.py file somewhere where it is 
 being found and the second one is causing a conflict.

 Graham
  

>  On Sun, Jan 23, 2011 at 11:02 PM, Kimberly Harvey 
> wrote:
>
>>  Sorry about that, there is nothing showing for either  echo 
>> $PYTHONPATH and  echo $DJANGO_SETTINGS_MODULE
>>
>> I am currently reading your messages.
>>
>>
>>  On Sun, Jan 23, 2011 at 10:55 PM, Graham Dumpleton <
>> grah...@gmail.com> wrote:
>>
>>>
>>>
>>> On Monday, January 24, 2011 3:44:59 PM UTC+11, Kimberly wrote:

 Please do the following and provide the output:

   pwd

 MY OUTPUT: /home/username/wikicamp

 Now run 'python' from the command line and do the following, 
 providing the output to us:

   import settings
   print settings.__file__

   import wikicamp.settings
   print wikicamp.settings.__file__

 after importing setting
 print settings.__file__
 OUTPUT: settings.pyc

  import wikicamp.settings 
   print wikicamp.settings.__file__

 OUTPUT: wikicamp/settings.pyc

>>>
>>> Unfortunately you did not show what PYTHONPATH, or 
>>> DJANGO_SETTINGS_MODULE was set to in environment to eliminate them as 
>>> cause, 
>>> but the above suggests that you have two Django projects created. One 
>>> is at:
>>>
>>>   /home/username/wikicamp
>>>
>>> and the other at:
>>>
>>>   /home/username/wikicamp/wikicamp
>>>
>>> Can you confirm this by indicating whether then file:
>>>
>>>   /home/username/wikicamp/wikicamp/settings.py
>>>
>>> exists.
>>>
>>> If this is write, then what is happening is that when syncb is being 
>>> running it is actually picking up the settings file from that second 
>>> site 
>>> nested within the first.
>>>
>>> If that is what has been done, then do:
>>>
>>>
>>>   mv /home/username/wikicamp/wikicamp 
>>> /home/username/wikicamp/wikicamp.broken
>>>
>>> Also be aware that you shouldn't create Django apps with the same 
>>> name as the project either, as the duplication of name can cause 
>>> problems 
>>> there as well, although for an app

Re: Django Improper Configuration

[Kimberly Harvey]

Screen:

You just installed Django's auth system, which means you don't have any
superusers defined.

So it is working

I do have a question... after I've used the move technique to move the
settings.py settings.py.broken which places all of the file of settings.py
inside the settings.py.broken. I then MOVED the file again from
settings.py.broken to settings.py and at the command line, python manage.py
syncdb it works! May I ask why it worked like that?

On Sun, Jan 23, 2011 at 11:32 PM, Graham Dumpleton <
graham.dumple...@gmail.com> wrote:

>
>
> On Monday, January 24, 2011 4:25:52 PM UTC+11, Kimberly wrote:
>>
>> The directory I did it from was from my home directory. I've moved the
>> files like you've indicated by using mv settings.py settings.py.broken.
>>
>> Should I go ahead and type in the command as python manage.py syncdb to
>> see if it works?
>>
>
> YES. YES. YES.
>
> :-)
>
> Graham
>
>
>
>>
>> On Sun, Jan 23, 2011 at 11:17 PM, Graham Dumpleton > > wrote:
>>
>>>
>>>
>>> On Monday, January 24, 2011 4:10:15 PM UTC+11, Kimberly wrote:


   /home/username/wikicamp/wikicamp/settings.py -->  THIS DOES NOT EXIST

 WHAT DOES EXIST: /home/username/wikicamp and inside that directory,
 settings.py is there.

>>>
>>> Earlier you said you got:
>>>
>>>   import settings
>>>   print settings.__file__
>>>
>>>   import wikicamp.settings
>>>   print wikicamp.settings.__file__
>>>
>>>   after importing setting
>>>   print settings.__file__
>>>   OUTPUT: settings.pyc
>>>
>>>   import wikicamp.settings
>>>   print wikicamp.settings.__file__
>>>
>>>   OUTPUT: wikicamp/settings.pyc
>>>
>>> What directory did you do that from.
>>>
>>> If you didn't run this from inside of site directory as was expecting and
>>> you did it from your home directory, then you have a settings.py sitting in
>>> your home directory which is the problem. Rename any settings.py file you
>>> home directory to something else.
>>>
>>>   mv ~/settings.py ~/settings.py.broken
>>>
>>> In short, you have more than one settings.py file somewhere where it is
>>> being found and the second one is causing a conflict.
>>>
>>> Graham
>>>
>>>
 On Sun, Jan 23, 2011 at 11:02 PM, Kimberly Harvey wrote:

>  Sorry about that, there is nothing showing for either  echo
> $PYTHONPATH and  echo $DJANGO_SETTINGS_MODULE
>
> I am currently reading your messages.
>
>
> On Sun, Jan 23, 2011 at 10:55 PM, Graham Dumpleton  > wrote:
>
>>
>>
>> On Monday, January 24, 2011 3:44:59 PM UTC+11, Kimberly wrote:
>>>
>>> Please do the following and provide the output:
>>>
>>>   pwd
>>>
>>> MY OUTPUT: /home/username/wikicamp
>>>
>>> Now run 'python' from the command line and do the following,
>>> providing the output to us:
>>>
>>>   import settings
>>>   print settings.__file__
>>>
>>>   import wikicamp.settings
>>>   print wikicamp.settings.__file__
>>>
>>> after importing setting
>>> print settings.__file__
>>> OUTPUT: settings.pyc
>>>
>>>  import wikicamp.settings
>>>   print wikicamp.settings.__file__
>>>
>>> OUTPUT: wikicamp/settings.pyc
>>>
>>
>> Unfortunately you did not show what PYTHONPATH, or
>> DJANGO_SETTINGS_MODULE was set to in environment to eliminate them as 
>> cause,
>> but the above suggests that you have two Django projects created. One is 
>> at:
>>
>>   /home/username/wikicamp
>>
>> and the other at:
>>
>>   /home/username/wikicamp/wikicamp
>>
>> Can you confirm this by indicating whether then file:
>>
>>   /home/username/wikicamp/wikicamp/settings.py
>>
>> exists.
>>
>> If this is write, then what is happening is that when syncb is being
>> running it is actually picking up the settings file from that second site
>> nested within the first.
>>
>> If that is what has been done, then do:
>>
>>
>>   mv /home/username/wikicamp/wikicamp 
>> /home/username/wikicamp/wikicamp.broken
>>
>> Also be aware that you shouldn't create Django apps with the same name
>> as the project either, as the duplication of name can cause problems 
>> there
>> as well, although for an app you wouldn't have a settings.py file in it,
>> which in this case it seems you do.
>>
>> Graham
>>
>>
>>> These might produce exceptions depending on where you current working
>>> directory is.
>>>
>>> This is to show whether you may have created a backup copy of
>>> settings.py file somewhere which is being found instead of that in same
>>> directory as manage.py.
>>>
>>> Finally, if you have modified manage.py, tell is what you have
>>> changed it to.
>>>
>>>
>>>
>>> On Sun, Jan 23, 2011 at 10:27 PM, Graham Dumpleton <
>>> grah...@gmail.com> wrote:
>>>


 On Monday, January 24, 

Re: Django Improper Configuration

[Graham Dumpleton]

On Monday, January 24, 2011 4:25:52 PM UTC+11, Kimberly wrote:
>
> The directory I did it from was from my home directory. I've moved the 
> files like you've indicated by using mv settings.py settings.py.broken.
>
> Should I go ahead and type in the command as python manage.py syncdb to see 
> if it works? 
>

YES. YES. YES.

:-)

Graham

 

>
> On Sun, Jan 23, 2011 at 11:17 PM, Graham Dumpleton 
> wrote:
>
>>
>>
>> On Monday, January 24, 2011 4:10:15 PM UTC+11, Kimberly wrote:
>>>
>>>
>>>   /home/username/wikicamp/wikicamp/settings.py -->  THIS DOES NOT EXIST
>>>
>>> WHAT DOES EXIST: /home/username/wikicamp and inside that directory, 
>>> settings.py is there.
>>>
>>
>> Earlier you said you got:
>>
>>   import settings
>>   print settings.__file__
>>
>>   import wikicamp.settings
>>   print wikicamp.settings.__file__
>>
>>   after importing setting
>>   print settings.__file__
>>   OUTPUT: settings.pyc
>>
>>   import wikicamp.settings
>>   print wikicamp.settings.__file__
>>
>>   OUTPUT: wikicamp/settings.pyc
>>
>> What directory did you do that from.
>>
>> If you didn't run this from inside of site directory as was expecting and 
>> you did it from your home directory, then you have a settings.py sitting in 
>> your home directory which is the problem. Rename any settings.py file you 
>> home directory to something else.
>>
>>   mv ~/settings.py ~/settings.py.broken
>>
>> In short, you have more than one settings.py file somewhere where it is 
>> being found and the second one is causing a conflict.
>>
>> Graham
>>  
>>
>>> On Sun, Jan 23, 2011 at 11:02 PM, Kimberly Harvey wrote:
>>>
  Sorry about that, there is nothing showing for either  echo $PYTHONPATH 
 and  echo $DJANGO_SETTINGS_MODULE

 I am currently reading your messages.


 On Sun, Jan 23, 2011 at 10:55 PM, Graham Dumpleton 
 wrote:

>
>
> On Monday, January 24, 2011 3:44:59 PM UTC+11, Kimberly wrote:
>>
>> Please do the following and provide the output:
>>
>>   pwd
>>
>> MY OUTPUT: /home/username/wikicamp
>>
>> Now run 'python' from the command line and do the following, providing 
>> the output to us:
>>
>>   import settings
>>   print settings.__file__
>>
>>   import wikicamp.settings
>>   print wikicamp.settings.__file__
>>
>> after importing setting
>> print settings.__file__
>> OUTPUT: settings.pyc
>>
>>  import wikicamp.settings 
>>   print wikicamp.settings.__file__
>>
>> OUTPUT: wikicamp/settings.pyc
>>
>
> Unfortunately you did not show what PYTHONPATH, or 
> DJANGO_SETTINGS_MODULE was set to in environment to eliminate them as 
> cause, 
> but the above suggests that you have two Django projects created. One is 
> at:
>
>   /home/username/wikicamp
>
> and the other at:
>
>   /home/username/wikicamp/wikicamp
>
> Can you confirm this by indicating whether then file:
>
>   /home/username/wikicamp/wikicamp/settings.py
>
> exists.
>
> If this is write, then what is happening is that when syncb is being 
> running it is actually picking up the settings file from that second site 
> nested within the first.
>
> If that is what has been done, then do:
>
>
>   mv /home/username/wikicamp/wikicamp 
> /home/username/wikicamp/wikicamp.broken
>
> Also be aware that you shouldn't create Django apps with the same name 
> as the project either, as the duplication of name can cause problems 
> there 
> as well, although for an app you wouldn't have a settings.py file in it, 
> which in this case it seems you do.
>
> Graham
>  
>
>> These might produce exceptions depending on where you current working 
>> directory is.
>>
>> This is to show whether you may have created a backup copy of 
>> settings.py file somewhere which is being found instead of that in same 
>> directory as manage.py.
>>
>> Finally, if you have modified manage.py, tell is what you have changed 
>> it to.
>>
>>
>>
>> On Sun, Jan 23, 2011 at 10:27 PM, Graham Dumpleton > > wrote:
>>
>>>
>>>
>>> On Monday, January 24, 2011 3:18:45 PM UTC+11, Kimberly wrote:

 Traceback ( most recent call last):
  File "manage.py", line 11, in 
 execute_manager(settings)
 File "/usr/lib/python2.5/site-
 packages/django/core/management/_init_.py", line 438, in execute 
 manager
 File 
 "/usr/lib/python2.5/site-packages/django/core/management/_init_.py", 
 line 
 379, in execute
   self.fetch_command(subcommand).run_from_argv(self.argv)
 File 
 "/usr/lib/python2.5/site-packages/django/core/management/base.py", 
 line 191, 
 in run_from_argv
 self.exectured(*args, **options.

Re: Django Improper Configuration

[Kimberly Harvey]

I ran the syncdb and it says it doesn't recognize the wiki module. Also,
when I moved the original file which was settings.py to settings.py.broken,
that means I have to change the formats in the manage,py and other files so
that it recognizes the settings.py.broken file, right?

On Sun, Jan 23, 2011 at 11:25 PM, Kimberly Harvey wrote:

> The directory I did it from was from my home directory. I've moved the
> files like you've indicated by using mv settings.py settings.py.broken.
>
> Should I go ahead and type in the command as python manage.py syncdb to see
> if it works?
>
> On Sun, Jan 23, 2011 at 11:17 PM, Graham Dumpleton <
> graham.dumple...@gmail.com> wrote:
>
>>
>>
>> On Monday, January 24, 2011 4:10:15 PM UTC+11, Kimberly wrote:
>>>
>>>
>>>   /home/username/wikicamp/wikicamp/settings.py -->  THIS DOES NOT EXIST
>>>
>>> WHAT DOES EXIST: /home/username/wikicamp and inside that directory,
>>> settings.py is there.
>>>
>>
>> Earlier you said you got:
>>
>>   import settings
>>   print settings.__file__
>>
>>   import wikicamp.settings
>>   print wikicamp.settings.__file__
>>
>>   after importing setting
>>   print settings.__file__
>>   OUTPUT: settings.pyc
>>
>>   import wikicamp.settings
>>   print wikicamp.settings.__file__
>>
>>   OUTPUT: wikicamp/settings.pyc
>>
>> What directory did you do that from.
>>
>> If you didn't run this from inside of site directory as was expecting and
>> you did it from your home directory, then you have a settings.py sitting in
>> your home directory which is the problem. Rename any settings.py file you
>> home directory to something else.
>>
>>   mv ~/settings.py ~/settings.py.broken
>>
>> In short, you have more than one settings.py file somewhere where it is
>> being found and the second one is causing a conflict.
>>
>> Graham
>>
>>
>>> On Sun, Jan 23, 2011 at 11:02 PM, Kimberly Harvey wrote:
>>>
  Sorry about that, there is nothing showing for either  echo $PYTHONPATH
 and  echo $DJANGO_SETTINGS_MODULE

 I am currently reading your messages.


 On Sun, Jan 23, 2011 at 10:55 PM, Graham Dumpleton <
 graham.d...@gmail.com> wrote:

>
>
> On Monday, January 24, 2011 3:44:59 PM UTC+11, Kimberly wrote:
>>
>> Please do the following and provide the output:
>>
>>   pwd
>>
>> MY OUTPUT: /home/username/wikicamp
>>
>> Now run 'python' from the command line and do the following, providing
>> the output to us:
>>
>>   import settings
>>   print settings.__file__
>>
>>   import wikicamp.settings
>>   print wikicamp.settings.__file__
>>
>> after importing setting
>> print settings.__file__
>> OUTPUT: settings.pyc
>>
>>  import wikicamp.settings
>>   print wikicamp.settings.__file__
>>
>> OUTPUT: wikicamp/settings.pyc
>>
>
> Unfortunately you did not show what PYTHONPATH, or
> DJANGO_SETTINGS_MODULE was set to in environment to eliminate them as 
> cause,
> but the above suggests that you have two Django projects created. One is 
> at:
>
>   /home/username/wikicamp
>
> and the other at:
>
>   /home/username/wikicamp/wikicamp
>
> Can you confirm this by indicating whether then file:
>
>   /home/username/wikicamp/wikicamp/settings.py
>
> exists.
>
> If this is write, then what is happening is that when syncb is being
> running it is actually picking up the settings file from that second site
> nested within the first.
>
> If that is what has been done, then do:
>
>
>   mv /home/username/wikicamp/wikicamp 
> /home/username/wikicamp/wikicamp.broken
>
> Also be aware that you shouldn't create Django apps with the same name
> as the project either, as the duplication of name can cause problems there
> as well, although for an app you wouldn't have a settings.py file in it,
> which in this case it seems you do.
>
> Graham
>
>
>> These might produce exceptions depending on where you current working
>> directory is.
>>
>> This is to show whether you may have created a backup copy of
>> settings.py file somewhere which is being found instead of that in same
>> directory as manage.py.
>>
>> Finally, if you have modified manage.py, tell is what you have changed
>> it to.
>>
>>
>>
>> On Sun, Jan 23, 2011 at 10:27 PM, Graham Dumpleton <
>> graha...@gmail.com> wrote:
>>
>>>
>>>
>>> On Monday, January 24, 2011 3:18:45 PM UTC+11, Kimberly wrote:

 Traceback ( most recent call last):
  File "manage.py", line 11, in 
 execute_manager(settings)
 File "/usr/lib/python2.5/site-
 packages/django/core/management/_init_.py", line 438, in execute
 manager
 File
 "/usr/lib/python2.5/site-packages/django/core/management/_init_.py", 
 line

Re: Django Improper Configuration

[Kimberly Harvey]

The directory I did it from was from my home directory. I've moved the files
like you've indicated by using mv settings.py settings.py.broken.

Should I go ahead and type in the command as python manage.py syncdb to see
if it works?

On Sun, Jan 23, 2011 at 11:17 PM, Graham Dumpleton <
graham.dumple...@gmail.com> wrote:

>
>
> On Monday, January 24, 2011 4:10:15 PM UTC+11, Kimberly wrote:
>>
>>
>>   /home/username/wikicamp/wikicamp/settings.py -->  THIS DOES NOT EXIST
>>
>> WHAT DOES EXIST: /home/username/wikicamp and inside that directory,
>> settings.py is there.
>>
>
> Earlier you said you got:
>
>   import settings
>   print settings.__file__
>
>   import wikicamp.settings
>   print wikicamp.settings.__file__
>
>   after importing setting
>   print settings.__file__
>   OUTPUT: settings.pyc
>
>   import wikicamp.settings
>   print wikicamp.settings.__file__
>
>   OUTPUT: wikicamp/settings.pyc
>
> What directory did you do that from.
>
> If you didn't run this from inside of site directory as was expecting and
> you did it from your home directory, then you have a settings.py sitting in
> your home directory which is the problem. Rename any settings.py file you
> home directory to something else.
>
>   mv ~/settings.py ~/settings.py.broken
>
> In short, you have more than one settings.py file somewhere where it is
> being found and the second one is causing a conflict.
>
> Graham
>
>
>> On Sun, Jan 23, 2011 at 11:02 PM, Kimberly Harvey wrote:
>>
>>> Sorry about that, there is nothing showing for either  echo $PYTHONPATH
>>> and  echo $DJANGO_SETTINGS_MODULE
>>>
>>> I am currently reading your messages.
>>>
>>>
>>> On Sun, Jan 23, 2011 at 10:55 PM, Graham Dumpleton <
>>> graham.d...@gmail.com> wrote:
>>>


 On Monday, January 24, 2011 3:44:59 PM UTC+11, Kimberly wrote:
>
> Please do the following and provide the output:
>
>   pwd
>
> MY OUTPUT: /home/username/wikicamp
>
> Now run 'python' from the command line and do the following, providing
> the output to us:
>
>   import settings
>   print settings.__file__
>
>   import wikicamp.settings
>   print wikicamp.settings.__file__
>
> after importing setting
> print settings.__file__
> OUTPUT: settings.pyc
>
>  import wikicamp.settings
>   print wikicamp.settings.__file__
>
> OUTPUT: wikicamp/settings.pyc
>

 Unfortunately you did not show what PYTHONPATH, or
 DJANGO_SETTINGS_MODULE was set to in environment to eliminate them as 
 cause,
 but the above suggests that you have two Django projects created. One is 
 at:

   /home/username/wikicamp

 and the other at:

   /home/username/wikicamp/wikicamp

 Can you confirm this by indicating whether then file:

   /home/username/wikicamp/wikicamp/settings.py

 exists.

 If this is write, then what is happening is that when syncb is being
 running it is actually picking up the settings file from that second site
 nested within the first.

 If that is what has been done, then do:


   mv /home/username/wikicamp/wikicamp 
 /home/username/wikicamp/wikicamp.broken

 Also be aware that you shouldn't create Django apps with the same name
 as the project either, as the duplication of name can cause problems there
 as well, although for an app you wouldn't have a settings.py file in it,
 which in this case it seems you do.

 Graham


> These might produce exceptions depending on where you current working
> directory is.
>
> This is to show whether you may have created a backup copy of
> settings.py file somewhere which is being found instead of that in same
> directory as manage.py.
>
> Finally, if you have modified manage.py, tell is what you have changed
> it to.
>
>
>
> On Sun, Jan 23, 2011 at 10:27 PM, Graham Dumpleton  > wrote:
>
>>
>>
>> On Monday, January 24, 2011 3:18:45 PM UTC+11, Kimberly wrote:
>>>
>>> Traceback ( most recent call last):
>>>  File "manage.py", line 11, in 
>>> execute_manager(settings)
>>> File "/usr/lib/python2.5/site-
>>> packages/django/core/management/_init_.py", line 438, in execute
>>> manager
>>> File
>>> "/usr/lib/python2.5/site-packages/django/core/management/_init_.py", 
>>> line
>>> 379, in execute
>>>   self.fetch_command(subcommand).run_from_argv(self.argv)
>>> File
>>> "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 
>>> 191,
>>> in run_from_argv
>>> self.exectured(*args, **options._dict_)
>>> File
>>> "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 
>>> 220,
>>> in execute
>>> output = self.handle(*args, **options)
>>> File
>>> "/usr/lib/python2.5/site-packages/django/core/manag

Re: Django Improper Configuration

[Graham Dumpleton]

On Monday, January 24, 2011 4:10:15 PM UTC+11, Kimberly wrote:
>
>
>   /home/username/wikicamp/wikicamp/settings.py -->  THIS DOES NOT EXIST
>
> WHAT DOES EXIST: /home/username/wikicamp and inside that directory, 
> settings.py is there.
>

Earlier you said you got:

  import settings
  print settings.__file__

  import wikicamp.settings
  print wikicamp.settings.__file__

  after importing setting
  print settings.__file__
  OUTPUT: settings.pyc

  import wikicamp.settings
  print wikicamp.settings.__file__

  OUTPUT: wikicamp/settings.pyc

What directory did you do that from.

If you didn't run this from inside of site directory as was expecting and 
you did it from your home directory, then you have a settings.py sitting in 
your home directory which is the problem. Rename any settings.py file you 
home directory to something else.

  mv ~/settings.py ~/settings.py.broken

In short, you have more than one settings.py file somewhere where it is 
being found and the second one is causing a conflict.

Graham
 

> On Sun, Jan 23, 2011 at 11:02 PM, Kimberly Harvey wrote:
>
>> Sorry about that, there is nothing showing for either  echo $PYTHONPATH 
>> and  echo $DJANGO_SETTINGS_MODULE
>>
>> I am currently reading your messages.
>>
>>
>> On Sun, Jan 23, 2011 at 10:55 PM, Graham Dumpleton > > wrote:
>>
>>>
>>>
>>> On Monday, January 24, 2011 3:44:59 PM UTC+11, Kimberly wrote:

 Please do the following and provide the output:

   pwd

 MY OUTPUT: /home/username/wikicamp

 Now run 'python' from the command line and do the following, providing 
 the output to us:

   import settings
   print settings.__file__

   import wikicamp.settings
   print wikicamp.settings.__file__

 after importing setting
 print settings.__file__
 OUTPUT: settings.pyc

  import wikicamp.settings 
   print wikicamp.settings.__file__

 OUTPUT: wikicamp/settings.pyc

>>>
>>> Unfortunately you did not show what PYTHONPATH, or DJANGO_SETTINGS_MODULE 
>>> was set to in environment to eliminate them as cause, but the above 
>>> suggests 
>>> that you have two Django projects created. One is at:
>>>
>>>   /home/username/wikicamp
>>>
>>> and the other at:
>>>
>>>   /home/username/wikicamp/wikicamp
>>>
>>> Can you confirm this by indicating whether then file:
>>>
>>>   /home/username/wikicamp/wikicamp/settings.py
>>>
>>> exists.
>>>
>>> If this is write, then what is happening is that when syncb is being 
>>> running it is actually picking up the settings file from that second site 
>>> nested within the first.
>>>
>>> If that is what has been done, then do:
>>>
>>>
>>>   mv /home/username/wikicamp/wikicamp 
>>> /home/username/wikicamp/wikicamp.broken
>>>
>>> Also be aware that you shouldn't create Django apps with the same name as 
>>> the project either, as the duplication of name can cause problems there as 
>>> well, although for an app you wouldn't have a settings.py file in it, which 
>>> in this case it seems you do.
>>>
>>> Graham
>>>  
>>>
 These might produce exceptions depending on where you current working 
 directory is.

 This is to show whether you may have created a backup copy of 
 settings.py file somewhere which is being found instead of that in same 
 directory as manage.py.

 Finally, if you have modified manage.py, tell is what you have changed 
 it to.



 On Sun, Jan 23, 2011 at 10:27 PM, Graham Dumpleton 
 wrote:

>
>
> On Monday, January 24, 2011 3:18:45 PM UTC+11, Kimberly wrote:
>>
>> Traceback ( most recent call last):
>>  File "manage.py", line 11, in 
>> execute_manager(settings)
>> File "/usr/lib/python2.5/site-
>> packages/django/core/management/_init_.py", line 438, in execute 
>> manager
>> File 
>> "/usr/lib/python2.5/site-packages/django/core/management/_init_.py", 
>> line 
>> 379, in execute
>>   self.fetch_command(subcommand).run_from_argv(self.argv)
>> File 
>> "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 
>> 191, 
>> in run_from_argv
>> self.exectured(*args, **options._dict_)
>> File 
>> "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 
>> 220, 
>> in execute
>> output = self.handle(*args, **options)
>> File 
>> "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 
>> 351, 
>> in handle
>>return self.handle_noargs(**options)
>> File 
>> "/usr/lib/python2.5/site-packages/django/core/management/commands/syncdb.py",
>>  
>> line 52, in handle_noargs
>> cursor = connection.cursor()
>> File 
>> "/usr/lib/python2.5/site-packages/django/db/backends/dummy/base.py", 
>> line 
>> 15, in complain
>> raise ImproperlyConfigured("You hav
>> en't set the database ENGINE setting yet.")
>

Re: Django Improper Configuration

[Kimberly Harvey]

  /home/username/wikicamp/wikicamp/settings.py -->  THIS DOES NOT EXIST

WHAT DOES EXIST: /home/username/wikicamp and inside that directory,
settings.py is there.


On Sun, Jan 23, 2011 at 11:02 PM, Kimberly Harvey wrote:

> Sorry about that, there is nothing showing for either  echo $PYTHONPATH
> and  echo $DJANGO_SETTINGS_MODULE
>
> I am currently reading your messages.
>
>
> On Sun, Jan 23, 2011 at 10:55 PM, Graham Dumpleton <
> graham.dumple...@gmail.com> wrote:
>
>>
>>
>> On Monday, January 24, 2011 3:44:59 PM UTC+11, Kimberly wrote:
>>>
>>> Please do the following and provide the output:
>>>
>>>   pwd
>>>
>>> MY OUTPUT: /home/username/wikicamp
>>>
>>> Now run 'python' from the command line and do the following, providing
>>> the output to us:
>>>
>>>   import settings
>>>   print settings.__file__
>>>
>>>   import wikicamp.settings
>>>   print wikicamp.settings.__file__
>>>
>>> after importing setting
>>> print settings.__file__
>>> OUTPUT: settings.pyc
>>>
>>>  import wikicamp.settings
>>>   print wikicamp.settings.__file__
>>>
>>> OUTPUT: wikicamp/settings.pyc
>>>
>>
>> Unfortunately you did not show what PYTHONPATH, or DJANGO_SETTINGS_MODULE
>> was set to in environment to eliminate them as cause, but the above suggests
>> that you have two Django projects created. One is at:
>>
>>   /home/username/wikicamp
>>
>> and the other at:
>>
>>   /home/username/wikicamp/wikicamp
>>
>> Can you confirm this by indicating whether then file:
>>
>>   /home/username/wikicamp/wikicamp/settings.py
>>
>> exists.
>>
>> If this is write, then what is happening is that when syncb is being
>> running it is actually picking up the settings file from that second site
>> nested within the first.
>>
>> If that is what has been done, then do:
>>
>>
>>   mv /home/username/wikicamp/wikicamp /home/username/wikicamp/wikicamp.broken
>>
>> Also be aware that you shouldn't create Django apps with the same name as
>> the project either, as the duplication of name can cause problems there as
>> well, although for an app you wouldn't have a settings.py file in it, which
>> in this case it seems you do.
>>
>> Graham
>>
>>
>>> These might produce exceptions depending on where you current working
>>> directory is.
>>>
>>> This is to show whether you may have created a backup copy of settings.py
>>> file somewhere which is being found instead of that in same directory as
>>> manage.py.
>>>
>>> Finally, if you have modified manage.py, tell is what you have changed it
>>> to.
>>>
>>>
>>>
>>> On Sun, Jan 23, 2011 at 10:27 PM, Graham Dumpleton <
>>> graham.d...@gmail.com> wrote:
>>>


 On Monday, January 24, 2011 3:18:45 PM UTC+11, Kimberly wrote:
>
> Traceback ( most recent call last):
>  File "manage.py", line 11, in 
> execute_manager(settings)
> File "/usr/lib/python2.5/site-
> packages/django/core/management/_init_.py", line 438, in execute
> manager
> File
> "/usr/lib/python2.5/site-packages/django/core/management/_init_.py", line
> 379, in execute
>   self.fetch_command(subcommand).run_from_argv(self.argv)
> File
> "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 
> 191,
> in run_from_argv
> self.exectured(*args, **options._dict_)
> File "/usr/lib/python2.5/site-packages/django/core/management/base.py",
> line 220, in execute
> output = self.handle(*args, **options)
> File "/usr/lib/python2.5/site-packages/django/core/management/base.py",
> line 351, in handle
>return self.handle_noargs(**options)
> File
> "/usr/lib/python2.5/site-packages/django/core/management/commands/syncdb.py",
> line 52, in handle_noargs
> cursor = connection.cursor()
> File
> "/usr/lib/python2.5/site-packages/django/db/backends/dummy/base.py", line
> 15, in complain
> raise ImproperlyConfigured("You hav
> en't set the database ENGINE setting yet.")
>
> THE ABOVE IS when I typed python manage.py syncdb
>

 Okay, if you definitely 100% aren't seeing something like:

 /home/username/wikicamp/settings.pyc
 DATABASES { 'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME':
 'wiki.db', 'HOST': '', 'USER': '', 'PASSWORD':'', 'PORT':''}}

 when running syncdb, then having a hard time explaining why it isn't
 being loaded.

 Please do the following and provide the output:

   pwd

 This is to show us the directory you are in when you are running
 runserver and syncdb.

   echo $PYTHONPATH

 This is to show us if you have a custom Python module search path set in
 your environment.

   echo $DJANGO_SETTINGS_MODULE

 This is show is if you are setting where Django should find its settings
 module.

 Now run 'python' from the command line and do the following, providing
 the output to us:

   import settings
   print settings.

Re: Django Improper Configuration

[Kimberly Harvey]

Sorry about that, there is nothing showing for either  echo $PYTHONPATH and
echo $DJANGO_SETTINGS_MODULE

I am currently reading your messages.

On Sun, Jan 23, 2011 at 10:55 PM, Graham Dumpleton <
graham.dumple...@gmail.com> wrote:

>
>
> On Monday, January 24, 2011 3:44:59 PM UTC+11, Kimberly wrote:
>>
>> Please do the following and provide the output:
>>
>>   pwd
>>
>> MY OUTPUT: /home/username/wikicamp
>>
>> Now run 'python' from the command line and do the following, providing the
>> output to us:
>>
>>   import settings
>>   print settings.__file__
>>
>>   import wikicamp.settings
>>   print wikicamp.settings.__file__
>>
>> after importing setting
>> print settings.__file__
>> OUTPUT: settings.pyc
>>
>>  import wikicamp.settings
>>   print wikicamp.settings.__file__
>>
>> OUTPUT: wikicamp/settings.pyc
>>
>
> Unfortunately you did not show what PYTHONPATH, or DJANGO_SETTINGS_MODULE
> was set to in environment to eliminate them as cause, but the above suggests
> that you have two Django projects created. One is at:
>
>   /home/username/wikicamp
>
> and the other at:
>
>   /home/username/wikicamp/wikicamp
>
> Can you confirm this by indicating whether then file:
>
>   /home/username/wikicamp/wikicamp/settings.py
>
> exists.
>
> If this is write, then what is happening is that when syncb is being
> running it is actually picking up the settings file from that second site
> nested within the first.
>
> If that is what has been done, then do:
>
>
>   mv /home/username/wikicamp/wikicamp /home/username/wikicamp/wikicamp.broken
>
> Also be aware that you shouldn't create Django apps with the same name as
> the project either, as the duplication of name can cause problems there as
> well, although for an app you wouldn't have a settings.py file in it, which
> in this case it seems you do.
>
> Graham
>
>
>> These might produce exceptions depending on where you current working
>> directory is.
>>
>> This is to show whether you may have created a backup copy of settings.py
>> file somewhere which is being found instead of that in same directory as
>> manage.py.
>>
>> Finally, if you have modified manage.py, tell is what you have changed it
>> to.
>>
>>
>>
>> On Sun, Jan 23, 2011 at 10:27 PM, Graham Dumpleton > > wrote:
>>
>>>
>>>
>>> On Monday, January 24, 2011 3:18:45 PM UTC+11, Kimberly wrote:

 Traceback ( most recent call last):
  File "manage.py", line 11, in 
 execute_manager(settings)
 File "/usr/lib/python2.5/site-
 packages/django/core/management/_init_.py", line 438, in execute manager
 File
 "/usr/lib/python2.5/site-packages/django/core/management/_init_.py", line
 379, in execute
   self.fetch_command(subcommand).run_from_argv(self.argv)
 File
 "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 
 191,
 in run_from_argv
 self.exectured(*args, **options._dict_)
 File "/usr/lib/python2.5/site-packages/django/core/management/base.py",
 line 220, in execute
 output = self.handle(*args, **options)
 File "/usr/lib/python2.5/site-packages/django/core/management/base.py",
 line 351, in handle
return self.handle_noargs(**options)
 File
 "/usr/lib/python2.5/site-packages/django/core/management/commands/syncdb.py",
 line 52, in handle_noargs
 cursor = connection.cursor()
 File
 "/usr/lib/python2.5/site-packages/django/db/backends/dummy/base.py", line
 15, in complain
 raise ImproperlyConfigured("You hav
 en't set the database ENGINE setting yet.")

 THE ABOVE IS when I typed python manage.py syncdb

>>>
>>> Okay, if you definitely 100% aren't seeing something like:
>>>
>>> /home/username/wikicamp/settings.pyc
>>> DATABASES { 'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME':
>>> 'wiki.db', 'HOST': '', 'USER': '', 'PASSWORD':'', 'PORT':''}}
>>>
>>> when running syncdb, then having a hard time explaining why it isn't
>>> being loaded.
>>>
>>> Please do the following and provide the output:
>>>
>>>   pwd
>>>
>>> This is to show us the directory you are in when you are running
>>> runserver and syncdb.
>>>
>>>   echo $PYTHONPATH
>>>
>>> This is to show us if you have a custom Python module search path set in
>>> your environment.
>>>
>>>   echo $DJANGO_SETTINGS_MODULE
>>>
>>> This is show is if you are setting where Django should find its settings
>>> module.
>>>
>>> Now run 'python' from the command line and do the following, providing
>>> the output to us:
>>>
>>>   import settings
>>>   print settings.__file__
>>>
>>>   import wikicamp.settings
>>>   print wikicamp.settings.__file__
>>>
>>> These might produce exceptions depending on where you current working
>>> directory is.
>>>
>>> This is to show whether you may have created a backup copy of settings.py
>>> file somewhere which is being found instead of that in same directory as
>>> manage.py.
>>>
>>> Finally, if you have modified manage.py, tell is what

Re: Django Improper Configuration

[Graham Dumpleton]

On Monday, January 24, 2011 3:44:59 PM UTC+11, Kimberly wrote:
>
> Please do the following and provide the output:
>
>   pwd
>
> MY OUTPUT: /home/username/wikicamp
>
> Now run 'python' from the command line and do the following, providing the 
> output to us:
>
>   import settings
>   print settings.__file__
>
>   import wikicamp.settings
>   print wikicamp.settings.__file__
>
> after importing setting
> print settings.__file__
> OUTPUT: settings.pyc
>
>  import wikicamp.settings 
>   print wikicamp.settings.__file__
>
> OUTPUT: wikicamp/settings.pyc
>

Unfortunately you did not show what PYTHONPATH, or DJANGO_SETTINGS_MODULE 
was set to in environment to eliminate them as cause, but the above suggests 
that you have two Django projects created. One is at:

  /home/username/wikicamp

and the other at:

  /home/username/wikicamp/wikicamp

Can you confirm this by indicating whether then file:

  /home/username/wikicamp/wikicamp/settings.py

exists.

If this is write, then what is happening is that when syncb is being running 
it is actually picking up the settings file from that second site nested 
within the first.

If that is what has been done, then do:

  mv /home/username/wikicamp/wikicamp /home/username/wikicamp/wikicamp.broken

Also be aware that you shouldn't create Django apps with the same name as 
the project either, as the duplication of name can cause problems there as 
well, although for an app you wouldn't have a settings.py file in it, which 
in this case it seems you do.

Graham
 

> These might produce exceptions depending on where you current working 
> directory is.
>
> This is to show whether you may have created a backup copy of settings.py 
> file somewhere which is being found instead of that in same directory as 
> manage.py.
>
> Finally, if you have modified manage.py, tell is what you have changed it 
> to.
>
>
>
> On Sun, Jan 23, 2011 at 10:27 PM, Graham Dumpleton 
> wrote:
>
>>
>>
>> On Monday, January 24, 2011 3:18:45 PM UTC+11, Kimberly wrote:
>>>
>>> Traceback ( most recent call last):
>>>  File "manage.py", line 11, in 
>>> execute_manager(settings)
>>> File "/usr/lib/python2.5/site-
>>> packages/django/core/management/_init_.py", line 438, in execute manager
>>> File 
>>> "/usr/lib/python2.5/site-packages/django/core/management/_init_.py", line 
>>> 379, in execute
>>>   self.fetch_command(subcommand).run_from_argv(self.argv)
>>> File 
>>> "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 
>>> 191, 
>>> in run_from_argv
>>> self.exectured(*args, **options._dict_)
>>> File "/usr/lib/python2.5/site-packages/django/core/management/base.py", 
>>> line 220, in execute
>>> output = self.handle(*args, **options)
>>> File "/usr/lib/python2.5/site-packages/django/core/management/base.py", 
>>> line 351, in handle
>>>return self.handle_noargs(**options)
>>> File 
>>> "/usr/lib/python2.5/site-packages/django/core/management/commands/syncdb.py",
>>>  
>>> line 52, in handle_noargs
>>> cursor = connection.cursor()
>>> File "/usr/lib/python2.5/site-packages/django/db/backends/dummy/base.py", 
>>> line 15, in complain
>>> raise ImproperlyConfigured("You hav
>>> en't set the database ENGINE setting yet.")
>>>
>>> THE ABOVE IS when I typed python manage.py syncdb
>>>
>>
>> Okay, if you definitely 100% aren't seeing something like:
>>
>> /home/username/wikicamp/settings.pyc
>> DATABASES { 'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME': 
>> 'wiki.db', 'HOST': '', 'USER': '', 'PASSWORD':'', 'PORT':''}}
>>
>> when running syncdb, then having a hard time explaining why it isn't being 
>> loaded.
>>
>> Please do the following and provide the output:
>>
>>   pwd
>>
>> This is to show us the directory you are in when you are running runserver 
>> and syncdb.
>>
>>   echo $PYTHONPATH
>>
>> This is to show us if you have a custom Python module search path set in 
>> your environment.
>>
>>   echo $DJANGO_SETTINGS_MODULE
>>
>> This is show is if you are setting where Django should find its settings 
>> module.
>>
>> Now run 'python' from the command line and do the following, providing the 
>> output to us:
>>
>>   import settings
>>   print settings.__file__
>>
>>   import wikicamp.settings
>>   print wikicamp.settings.__file__
>>
>> These might produce exceptions depending on where you current working 
>> directory is.
>>
>> This is to show whether you may have created a backup copy of settings.py 
>> file somewhere which is being found instead of that in same directory as 
>> manage.py.
>>
>> Finally, if you have modified manage.py, tell is what you have changed it 
>> to.
>>
>> Graham
>>
>> Below is when I ran the python manage.py runserver
>>> /home/username/wikicamp/settings.pyc
>>> DATABASES { 'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME': 
>>> 'wiki.db', 'HOST': '', 'USER': '', 'PASSWORD':'', 'PORT':''}}
>>> validating models...
>>> 0 errors found
>>>
>>> Django version 1.2.4, using settings 'wikica

Re: how to remove add and change links on admin dashboard

[Subhranath Chunder]

Override the templates.

On 23 Jan 2011 07:12, "rahul jain"  wrote:

Hi Guys,

how to remove add and change links + icons on admin dashboard ?

Thanks.

Rahul




 --
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: Django Improper Configuration

[Kimberly Harvey]

I did not modified the manage.py file





On Sun, Jan 23, 2011 at 10:44 PM, Kimberly Harvey wrote:

> Please do the following and provide the output:
>
>   pwd
>
> MY OUTPUT: /home/username/wikicamp
>
> Now run 'python' from the command line and do the following, providing the
> output to us:
>
>   import settings
>   print settings.__file__
>
>   import wikicamp.settings
>   print wikicamp.settings.__file__
>
> after importing setting
> print settings.__file__
> OUTPUT: settings.pyc
>
>  import wikicamp.settings
>   print wikicamp.settings.__file__
>
> OUTPUT: wikicamp/settings.pyc
>
> These might produce exceptions depending on where you current working
> directory is.
>
> This is to show whether you may have created a backup copy of settings.py
> file somewhere which is being found instead of that in same directory as
> manage.py.
>
> Finally, if you have modified manage.py, tell is what you have changed it
> to.
>
>
>
> On Sun, Jan 23, 2011 at 10:27 PM, Graham Dumpleton <
> graham.dumple...@gmail.com> wrote:
>
>>
>>
>> On Monday, January 24, 2011 3:18:45 PM UTC+11, Kimberly wrote:
>>>
>>> Traceback ( most recent call last):
>>>  File "manage.py", line 11, in 
>>> execute_manager(settings)
>>> File "/usr/lib/python2.5/site-
>>> packages/django/core/management/_init_.py", line 438, in execute manager
>>> File
>>> "/usr/lib/python2.5/site-packages/django/core/management/_init_.py", line
>>> 379, in execute
>>>   self.fetch_command(subcommand).run_from_argv(self.argv)
>>> File
>>> "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 191,
>>> in run_from_argv
>>> self.exectured(*args, **options._dict_)
>>> File "/usr/lib/python2.5/site-packages/django/core/management/base.py",
>>> line 220, in execute
>>> output = self.handle(*args, **options)
>>> File "/usr/lib/python2.5/site-packages/django/core/management/base.py",
>>> line 351, in handle
>>>return self.handle_noargs(**options)
>>> File
>>> "/usr/lib/python2.5/site-packages/django/core/management/commands/syncdb.py",
>>> line 52, in handle_noargs
>>> cursor = connection.cursor()
>>> File "/usr/lib/python2.5/site-packages/django/db/backends/dummy/base.py",
>>> line 15, in complain
>>> raise ImproperlyConfigured("You hav
>>> en't set the database ENGINE setting yet.")
>>>
>>> THE ABOVE IS when I typed python manage.py syncdb
>>>
>>
>> Okay, if you definitely 100% aren't seeing something like:
>>
>> /home/username/wikicamp/settings.pyc
>> DATABASES { 'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME':
>> 'wiki.db', 'HOST': '', 'USER': '', 'PASSWORD':'', 'PORT':''}}
>>
>> when running syncdb, then having a hard time explaining why it isn't being
>> loaded.
>>
>> Please do the following and provide the output:
>>
>>   pwd
>>
>> This is to show us the directory you are in when you are running runserver
>> and syncdb.
>>
>>   echo $PYTHONPATH
>>
>> This is to show us if you have a custom Python module search path set in
>> your environment.
>>
>>   echo $DJANGO_SETTINGS_MODULE
>>
>> This is show is if you are setting where Django should find its settings
>> module.
>>
>> Now run 'python' from the command line and do the following, providing the
>> output to us:
>>
>>   import settings
>>   print settings.__file__
>>
>>   import wikicamp.settings
>>   print wikicamp.settings.__file__
>>
>> These might produce exceptions depending on where you current working
>> directory is.
>>
>> This is to show whether you may have created a backup copy of settings.py
>> file somewhere which is being found instead of that in same directory as
>> manage.py.
>>
>> Finally, if you have modified manage.py, tell is what you have changed it
>> to.
>>
>> Graham
>>
>> Below is when I ran the python manage.py runserver
>>> /home/username/wikicamp/settings.pyc
>>> DATABASES { 'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME':
>>> 'wiki.db', 'HOST': '', 'USER': '', 'PASSWORD':'', 'PORT':''}}
>>> validating models...
>>> 0 errors found
>>>
>>> Django version 1.2.4, using settings 'wikicamp.settings'
>>> Development server is running at http://127.0.0.1:8000/
>>> Quit the server with CONTROL -C
>>>
>>> Those are the outputs after y
>>>
>>>
>>> On Sun, Jan 23, 2011 at 10:11 PM, Graham Dumpleton <
>>> graham.d...@gmail.com> wrote:
>>>


 On Monday, January 24, 2011 2:55:16 PM UTC+11, Graham Dumpleton wrote:
>
> Are you saying that those two print statements you were told to add are
> not causing anything additional to be displayed on the screen when you run
> both runserver and syncdb?
>
> This is why I asked you to provide the output again. You may not
> understand what we are looking for. Don't care about what the error is at
> the point but the information that those print statements should have
> output.
>

 For the record, I would expect to see those print statements produce
 output at least twice. This is because settings.py actually gets 

Re: Django Improper Configuration

[Kimberly Harvey]

Please do the following and provide the output:

  pwd

MY OUTPUT: /home/username/wikicamp

Now run 'python' from the command line and do the following, providing the
output to us:

  import settings
  print settings.__file__

  import wikicamp.settings
  print wikicamp.settings.__file__

after importing setting
print settings.__file__
OUTPUT: settings.pyc

 import wikicamp.settings
  print wikicamp.settings.__file__

OUTPUT: wikicamp/settings.pyc

These might produce exceptions depending on where you current working
directory is.

This is to show whether you may have created a backup copy of settings.py
file somewhere which is being found instead of that in same directory as
manage.py.

Finally, if you have modified manage.py, tell is what you have changed it
to.



On Sun, Jan 23, 2011 at 10:27 PM, Graham Dumpleton <
graham.dumple...@gmail.com> wrote:

>
>
> On Monday, January 24, 2011 3:18:45 PM UTC+11, Kimberly wrote:
>>
>> Traceback ( most recent call last):
>>  File "manage.py", line 11, in 
>> execute_manager(settings)
>> File "/usr/lib/python2.5/site-
>> packages/django/core/management/_init_.py", line 438, in execute manager
>> File
>> "/usr/lib/python2.5/site-packages/django/core/management/_init_.py", line
>> 379, in execute
>>   self.fetch_command(subcommand).run_from_argv(self.argv)
>> File
>> "/usr/lib/python2.5/site-packages/django/core/management/base.py", line 191,
>> in run_from_argv
>> self.exectured(*args, **options._dict_)
>> File "/usr/lib/python2.5/site-packages/django/core/management/base.py",
>> line 220, in execute
>> output = self.handle(*args, **options)
>> File "/usr/lib/python2.5/site-packages/django/core/management/base.py",
>> line 351, in handle
>>return self.handle_noargs(**options)
>> File
>> "/usr/lib/python2.5/site-packages/django/core/management/commands/syncdb.py",
>> line 52, in handle_noargs
>> cursor = connection.cursor()
>> File "/usr/lib/python2.5/site-packages/django/db/backends/dummy/base.py",
>> line 15, in complain
>> raise ImproperlyConfigured("You hav
>> en't set the database ENGINE setting yet.")
>>
>> THE ABOVE IS when I typed python manage.py syncdb
>>
>
> Okay, if you definitely 100% aren't seeing something like:
>
> /home/username/wikicamp/settings.pyc
> DATABASES { 'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME':
> 'wiki.db', 'HOST': '', 'USER': '', 'PASSWORD':'', 'PORT':''}}
>
> when running syncdb, then having a hard time explaining why it isn't being
> loaded.
>
> Please do the following and provide the output:
>
>   pwd
>
> This is to show us the directory you are in when you are running runserver
> and syncdb.
>
>   echo $PYTHONPATH
>
> This is to show us if you have a custom Python module search path set in
> your environment.
>
>   echo $DJANGO_SETTINGS_MODULE
>
> This is show is if you are setting where Django should find its settings
> module.
>
> Now run 'python' from the command line and do the following, providing the
> output to us:
>
>   import settings
>   print settings.__file__
>
>   import wikicamp.settings
>   print wikicamp.settings.__file__
>
> These might produce exceptions depending on where you current working
> directory is.
>
> This is to show whether you may have created a backup copy of settings.py
> file somewhere which is being found instead of that in same directory as
> manage.py.
>
> Finally, if you have modified manage.py, tell is what you have changed it
> to.
>
> Graham
>
> Below is when I ran the python manage.py runserver
>> /home/username/wikicamp/settings.pyc
>> DATABASES { 'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME':
>> 'wiki.db', 'HOST': '', 'USER': '', 'PASSWORD':'', 'PORT':''}}
>> validating models...
>> 0 errors found
>>
>> Django version 1.2.4, using settings 'wikicamp.settings'
>> Development server is running at http://127.0.0.1:8000/
>> Quit the server with CONTROL -C
>>
>> Those are the outputs after y
>>
>>
>> On Sun, Jan 23, 2011 at 10:11 PM, Graham Dumpleton > > wrote:
>>
>>>
>>>
>>> On Monday, January 24, 2011 2:55:16 PM UTC+11, Graham Dumpleton wrote:

 Are you saying that those two print statements you were told to add are
 not causing anything additional to be displayed on the screen when you run
 both runserver and syncdb?

 This is why I asked you to provide the output again. You may not
 understand what we are looking for. Don't care about what the error is at
 the point but the information that those print statements should have
 output.

>>>
>>> For the record, I would expect to see those print statements produce
>>> output at least twice. This is because settings.py actually gets imported
>>> multiple times. So, for example I see:
>>>
>>> Grumpys-MacBook-Pro:mysite graham$ python manage.py runserver
>>> Traceback (most recent call last):
>>>   File "manage.py", line 2, in 
>>> from django.core.management import execute_manager
>>> ImportError: No module named django.core.ma

Re: Django Improper Configuration

[Graham Dumpleton]

On Monday, January 24, 2011 3:18:45 PM UTC+11, Kimberly wrote:
>
> Traceback ( most recent call last):
>  File "manage.py", line 11, in 
> execute_manager(settings)
> File "/usr/lib/python2.5/site-
> packages/django/core/management/_init_.py", line 438, in execute manager
> File 
> "/usr/lib/python2.5/site-packages/django/core/management/_init_.py", line 
> 379, in execute
>   self.fetch_command(subcommand).run_from_argv(self.argv)
> File "/usr/lib/python2.5/site-packages/django/core/management/base.py", 
> line 191, in run_from_argv
> self.exectured(*args, **options._dict_)
> File "/usr/lib/python2.5/site-packages/django/core/management/base.py", 
> line 220, in execute
> output = self.handle(*args, **options)
> File "/usr/lib/python2.5/site-packages/django/core/management/base.py", 
> line 351, in handle
>return self.handle_noargs(**options)
> File 
> "/usr/lib/python2.5/site-packages/django/core/management/commands/syncdb.py", 
> line 52, in handle_noargs
> cursor = connection.cursor()
> File "/usr/lib/python2.5/site-packages/django/db/backends/dummy/base.py", 
> line 15, in complain
> raise ImproperlyConfigured("You hav
> en't set the database ENGINE setting yet.")
>
> THE ABOVE IS when I typed python manage.py syncdb
>

Okay, if you definitely 100% aren't seeing something like:

/home/username/wikicamp/settings.pyc
DATABASES { 'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME': 
'wiki.db', 'HOST': '', 'USER': '', 'PASSWORD':'', 'PORT':''}}

when running syncdb, then having a hard time explaining why it isn't being 
loaded.

Please do the following and provide the output:

  pwd

This is to show us the directory you are in when you are running runserver 
and syncdb.

  echo $PYTHONPATH

This is to show us if you have a custom Python module search path set in 
your environment.

  echo $DJANGO_SETTINGS_MODULE

This is show is if you are setting where Django should find its settings 
module.

Now run 'python' from the command line and do the following, providing the 
output to us:

  import settings
  print settings.__file__

  import wikicamp.settings
  print wikicamp.settings.__file__

These might produce exceptions depending on where you current working 
directory is.

This is to show whether you may have created a backup copy of settings.py 
file somewhere which is being found instead of that in same directory as 
manage.py.

Finally, if you have modified manage.py, tell is what you have changed it 
to.

Graham

Below is when I ran the python manage.py runserver
> /home/username/wikicamp/settings.pyc
> DATABASES { 'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME': 
> 'wiki.db', 'HOST': '', 'USER': '', 'PASSWORD':'', 'PORT':''}}
> validating models...
> 0 errors found
>
> Django version 1.2.4, using settings 'wikicamp.settings'
> Development server is running at http://127.0.0.1:8000/
> Quit the server with CONTROL -C
>
> Those are the outputs after y
>
>
> On Sun, Jan 23, 2011 at 10:11 PM, Graham Dumpleton 
> wrote:
>
>>
>>
>> On Monday, January 24, 2011 2:55:16 PM UTC+11, Graham Dumpleton wrote:
>>>
>>> Are you saying that those two print statements you were told to add are 
>>> not causing anything additional to be displayed on the screen when you run 
>>> both runserver and syncdb?
>>>
>>> This is why I asked you to provide the output again. You may not 
>>> understand what we are looking for. Don't care about what the error is at 
>>> the point but the information that those print statements should have 
>>> output.
>>>
>>
>> For the record, I would expect to see those print statements produce 
>> output at least twice. This is because settings.py actually gets imported 
>> multiple times. So, for example I see:
>>
>> Grumpys-MacBook-Pro:mysite graham$ python manage.py runserver
>> Traceback (most recent call last):
>>   File "manage.py", line 2, in 
>> from django.core.management import execute_manager
>> ImportError: No module named django.core.management
>> Grumpys-MacBook-Pro:mysite graham$ source ../../bin/activate
>> (django-2)Grumpys-MacBook-Pro:mysite graham$ python manage.py runserver
>> /Library/WebServer/Sites/django-2/projects/mysite/settings.py
>> DATABASES {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME': 
>> '/Library/WebServer/Sites/django-2/db/database.db', 'HOST': '', 'USER': '', 
>> 'PASSWORD': '', 'PORT': ''}}
>> /Library/WebServer/Sites/django-2/projects/mysite/../mysite/settings.pyc
>> DATABASES {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME': 
>> '/Library/WebServer/Sites/django-2/db/database.db', 'HOST': '', 'USER': '', 
>> 'PASSWORD': '', 'PORT': ''}}
>> /Library/WebServer/Sites/django-2/projects/mysite/settings.pyc
>> DATABASES {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME': 
>> '/Library/WebServer/Sites/django-2/db/database.db', 'HOST': '', 'USER': '', 
>> 'PASSWORD': '', 'PORT': ''}}
>> /Library/WebServer/Sites/django-2/projects/mysite/../mysite/settings.pyc
>> DA

Re: django and scale9x (socallinuxexpo)

[Gerald Fontejon]

Thank you for spreading the word.  Would like to get a response by 
2/7/2011.  I am also working on getting some python representation from 
a local LA group (socal piggies).  Doubling up a python booth with 
django booth would be ideal.  Thanks again Russ.


-Gerald


On 1/21/11 8:36 PM, Russell Keith-Magee wrote:

On Sat, Jan 22, 2011 at 7:12 AM, gfonk  wrote:

Greetings Django users group,

I would like to invite the Django project to represent and attend the
9th Southern California Linux Expo.  The show will be held February
25th-27th, 2011 at the Hilton LAX in Los Angeles, CA.  SCALE 9x will
be an excellent venue to increase awareness and showcase the work of
Django.

Hi Gerald,

Thanks for the offer; I'll pass the word around and see if anybody is
interested.

How soon do you require a response?

Yours,
Russ Magee




--
Gerald Fontejon
e-mail: gerald.fonte...@gmail.com
mobile: 310.876.2350

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

[Kimberly Harvey]

The output was produced with the print __file__ and print 'DATABASES',
DATABASES at the end of the settings.py file.

On Sun, Jan 23, 2011 at 10:18 PM, Kimberly Harvey wrote:

> Traceback ( most recent call last):
>  File "manage.py", line 11, in 
> execute_manager(settings)
> File "/usr/lib/python2.5/site-
> packages/django/core/management/_init_.py", line 438, in execute manager
> File
> "/usr/lib/python2.5/site-packages/django/core/management/_init_.py", line
> 379, in execute
>   self.fetch_command(subcommand).run_from_argv(self.argv)
> File "/usr/lib/python2.5/site-packages/django/core/management/base.py",
> line 191, in run_from_argv
> self.exectured(*args, **options._dict_)
> File "/usr/lib/python2.5/site-packages/django/core/management/base.py",
> line 220, in execute
> output = self.handle(*args, **options)
> File "/usr/lib/python2.5/site-packages/django/core/management/base.py",
> line 351, in handle
>return self.handle_noargs(**options)
> File
> "/usr/lib/python2.5/site-packages/django/core/management/commands/syncdb.py",
> line 52, in handle_noargs
> cursor = connection.cursor()
> File "/usr/lib/python2.5/site-packages/django/db/backends/dummy/base.py",
> line 15, in complain
> raise ImproperlyConfigured("You hav
> en't set the database ENGINE setting yet.")
>
> THE ABOVE IS when I typed python manage.py syncdb
>
>
>
>
> Below is when I ran the python manage.py runserver
> /home/username/wikicamp/settings.pyc
> DATABASES { 'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME':
> 'wiki.db', 'HOST': '', 'USER': '', 'PASSWORD':'', 'PORT':''}}
>
> validating models...
> 0 errors found
>
> Django version 1.2.4, using settings 'wikicamp.settings'
>
> Development server is running at http://127.0.0.1:8000/
> Quit the server with CONTROL -C
>
> Those are the outputs after y
>
>
> On Sun, Jan 23, 2011 at 10:11 PM, Graham Dumpleton <
> graham.dumple...@gmail.com> wrote:
>
>>
>>
>> On Monday, January 24, 2011 2:55:16 PM UTC+11, Graham Dumpleton wrote:
>>>
>>> Are you saying that those two print statements you were told to add are
>>> not causing anything additional to be displayed on the screen when you run
>>> both runserver and syncdb?
>>>
>>> This is why I asked you to provide the output again. You may not
>>> understand what we are looking for. Don't care about what the error is at
>>> the point but the information that those print statements should have
>>> output.
>>>
>>
>> For the record, I would expect to see those print statements produce
>> output at least twice. This is because settings.py actually gets imported
>> multiple times. So, for example I see:
>>
>> Grumpys-MacBook-Pro:mysite graham$ python manage.py runserver
>> Traceback (most recent call last):
>>   File "manage.py", line 2, in 
>> from django.core.management import execute_manager
>> ImportError: No module named django.core.management
>> Grumpys-MacBook-Pro:mysite graham$ source ../../bin/activate
>> (django-2)Grumpys-MacBook-Pro:mysite graham$ python manage.py runserver
>> /Library/WebServer/Sites/django-2/projects/mysite/settings.py
>> DATABASES {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME':
>> '/Library/WebServer/Sites/django-2/db/database.db', 'HOST': '', 'USER': '',
>> 'PASSWORD': '', 'PORT': ''}}
>> /Library/WebServer/Sites/django-2/projects/mysite/../mysite/settings.pyc
>> DATABASES {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME':
>> '/Library/WebServer/Sites/django-2/db/database.db', 'HOST': '', 'USER': '',
>> 'PASSWORD': '', 'PORT': ''}}
>> /Library/WebServer/Sites/django-2/projects/mysite/settings.pyc
>> DATABASES {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME':
>> '/Library/WebServer/Sites/django-2/db/database.db', 'HOST': '', 'USER': '',
>> 'PASSWORD': '', 'PORT': ''}}
>> /Library/WebServer/Sites/django-2/projects/mysite/../mysite/settings.pyc
>> DATABASES {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME':
>> '/Library/WebServer/Sites/django-2/db/database.db', 'HOST': '', 'USER': '',
>> 'PASSWORD': '', 'PORT': ''}}
>> Validating models...
>>
>> 0 errors found
>> Django version 1.3 beta 1, using settings 'mysite.settings'
>> Development server is running at http://127.0.0.1:8000/
>> Quit the server with CONTROL-C.
>>
>>
>> ^C(django-2)Grumpys-MacBook-Pro:mysite graham$ python manage.py syncdb
>> /Library/WebServer/Sites/django-2/projects/mysite/settings.pyc
>> DATABASES {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME':
>> '/Library/WebServer/Sites/django-2/db/database.db', 'HOST': '', 'USER': '',
>> 'PASSWORD': '', 'PORT': ''}}
>> /Library/WebServer/Sites/django-2/projects/mysite/../mysite/settings.pyc
>> DATABASES {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME':
>> '/Library/WebServer/Sites/django-2/db/database.db', 'HOST': '', 'USER': '',
>> 'PASSWORD': '', 'PORT': ''}}
>> Creating tables ...
>> Installing custom SQL ...
>> Installing indexes ...
>> No fixtures found.
>>
>> Don't get me start

Re: Django Improper Configuration

[Kimberly Harvey]

Traceback ( most recent call last):
 File "manage.py", line 11, in 
execute_manager(settings)
File "/usr/lib/python2.5/site-
packages/django/core/management/_init_.py", line 438, in execute manager
File
"/usr/lib/python2.5/site-packages/django/core/management/_init_.py", line
379, in execute
  self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/lib/python2.5/site-packages/django/core/management/base.py",
line 191, in run_from_argv
self.exectured(*args, **options._dict_)
File "/usr/lib/python2.5/site-packages/django/core/management/base.py", line
220, in execute
output = self.handle(*args, **options)
File "/usr/lib/python2.5/site-packages/django/core/management/base.py", line
351, in handle
   return self.handle_noargs(**options)
File
"/usr/lib/python2.5/site-packages/django/core/management/commands/syncdb.py",
line 52, in handle_noargs
cursor = connection.cursor()
File "/usr/lib/python2.5/site-packages/django/db/backends/dummy/base.py",
line 15, in complain
raise ImproperlyConfigured("You hav
en't set the database ENGINE setting yet.")

THE ABOVE IS when I typed python manage.py syncdb




Below is when I ran the python manage.py runserver
/home/username/wikicamp/settings.pyc
DATABASES { 'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME':
'wiki.db', 'HOST': '', 'USER': '', 'PASSWORD':'', 'PORT':''}}
validating models...
0 errors found

Django version 1.2.4, using settings 'wikicamp.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL -C

Those are the outputs after y


On Sun, Jan 23, 2011 at 10:11 PM, Graham Dumpleton <
graham.dumple...@gmail.com> wrote:

>
>
> On Monday, January 24, 2011 2:55:16 PM UTC+11, Graham Dumpleton wrote:
>>
>> Are you saying that those two print statements you were told to add are
>> not causing anything additional to be displayed on the screen when you run
>> both runserver and syncdb?
>>
>> This is why I asked you to provide the output again. You may not
>> understand what we are looking for. Don't care about what the error is at
>> the point but the information that those print statements should have
>> output.
>>
>
> For the record, I would expect to see those print statements produce output
> at least twice. This is because settings.py actually gets imported multiple
> times. So, for example I see:
>
> Grumpys-MacBook-Pro:mysite graham$ python manage.py runserver
> Traceback (most recent call last):
>   File "manage.py", line 2, in 
> from django.core.management import execute_manager
> ImportError: No module named django.core.management
> Grumpys-MacBook-Pro:mysite graham$ source ../../bin/activate
> (django-2)Grumpys-MacBook-Pro:mysite graham$ python manage.py runserver
> /Library/WebServer/Sites/django-2/projects/mysite/settings.py
> DATABASES {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME':
> '/Library/WebServer/Sites/django-2/db/database.db', 'HOST': '', 'USER': '',
> 'PASSWORD': '', 'PORT': ''}}
> /Library/WebServer/Sites/django-2/projects/mysite/../mysite/settings.pyc
> DATABASES {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME':
> '/Library/WebServer/Sites/django-2/db/database.db', 'HOST': '', 'USER': '',
> 'PASSWORD': '', 'PORT': ''}}
> /Library/WebServer/Sites/django-2/projects/mysite/settings.pyc
> DATABASES {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME':
> '/Library/WebServer/Sites/django-2/db/database.db', 'HOST': '', 'USER': '',
> 'PASSWORD': '', 'PORT': ''}}
> /Library/WebServer/Sites/django-2/projects/mysite/../mysite/settings.pyc
> DATABASES {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME':
> '/Library/WebServer/Sites/django-2/db/database.db', 'HOST': '', 'USER': '',
> 'PASSWORD': '', 'PORT': ''}}
> Validating models...
>
> 0 errors found
> Django version 1.3 beta 1, using settings 'mysite.settings'
> Development server is running at http://127.0.0.1:8000/
> Quit the server with CONTROL-C.
>
>
> ^C(django-2)Grumpys-MacBook-Pro:mysite graham$ python manage.py syncdb
> /Library/WebServer/Sites/django-2/projects/mysite/settings.pyc
> DATABASES {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME':
> '/Library/WebServer/Sites/django-2/db/database.db', 'HOST': '', 'USER': '',
> 'PASSWORD': '', 'PORT': ''}}
> /Library/WebServer/Sites/django-2/projects/mysite/../mysite/settings.pyc
> DATABASES {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME':
> '/Library/WebServer/Sites/django-2/db/database.db', 'HOST': '', 'USER': '',
> 'PASSWORD': '', 'PORT': ''}}
> Creating tables ...
> Installing custom SQL ...
> Installing indexes ...
> No fixtures found.
>
> Don't get me started on the multiple imports of settings.py file. :-(
>
> Graham
>
>
> On Monday, January 24, 2011 2:48:50 PM UTC+11, Kimberly wrote:
>>
>>> I've provided the full errors in the post, it is there. ( same errors as
>>> I've faced prior to adding the print __file__ and 'DATABASES', DATABASES) as
>>> I'm encountering the same after I'v

Re: Django Improper Configuration

[Kimberly Harvey]

Thank you for the advices. I've done some Python codes in the past and
recently. I already have a Python code that I will need to use to create a
Django website ( response to Steven).

(Response to Graham):
Traceback ( most recent call last):
 File "manage.py", line 11, in 
execute_manager(settings)
File "/usr/lib/python2.5/site-
packages/django/core/management/_init_.py", line 438, in execute manager
File
"/usr/lib/python2.5/site-packages/django/core/management/_init_.py", line
379, in execute
  self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/lib/python2.5/site-packages/django/core/management/base.py",
line 191, in run_from_argv
self.exectured(*args, **options._dict_)
File "/usr/lib/python2.5/site-packages/django/core/management/base.py", line
220, in execute
output = self.handle(*args, **options)
File "/usr/lib/python2.5/site-packages/django/core/management/base.py", line
351, in handle
   return self.handle_noargs(**options)
File
"/usr/lib/python2.5/site-packages/django/core/management/commands/syncdb.py",
line 52, in handle_noargs
cursor = connection.cursor()
File "/usr/lib/python2.5/site-packages/django/db/backends/dummy/base.py",
line 15, in complain
raise ImproperlyConfigured("You hav
en't set the database ENGINE setting yet.")


On Sun, Jan 23, 2011 at 9:54 PM, Steven Elliott Jr  wrote:

> Just curious if you've done a python tutorial yet? It's hard to really
> understand Django well unless you have at least some working knowledge of
> python. You will most definitely struggle later on when things become more
> complicated with your app. The framework is great for repetitive tasks but
> you're going to need to know how to write python code if you're to get
> anywhere.
>
> It's definitely possible to learn both at the same time but I'd read
> through, and work through a few python tutorials first then come back to
> Django.
>
> I know this is probably not what you'd like to hear and it's just my two
> cents so...
>
> Anyway, keep posting and we will try to help.
>
> -Steven
>
> On Jan 23, 2011, at 10:40 PM, Graham Dumpleton 
> wrote:
>
> That is two underscores, followed by 'file' followed by two underscores.
> Not just a single underscore.
>
> Please try and cut and paste out we give to use and vice versa. In other
> words, provide complete output showing full errors and tracebacks. Such
> information may be meaningful to use even if you think it isn't.
>
> Graham
>
> On Monday, January 24, 2011 2:35:06 PM UTC+11, Kimberly wrote:
>>
>> it says that the _file_ is not defined.
>>
>> On Sun, Jan 23, 2011 at 9:28 PM, Graham Dumpleton 
>> wrote:
>>
>>>
>>>
>>> On Monday, January 24, 2011 2:19:09 PM UTC+11, Steven Elliott Jr wrote:

 Copy and Paste the following to replace your entire DATABASES tuple:

 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.sqlite3',
 'NAME': 'database.db',
 'USER': '',
 'PASSWORD': '',
 'HOST': '',
 'PORT': '',
 }
 }

 it looks like in your configuration you are also missing a comma after
 the name of the database. Remember you must include that comma because this
 is a tuple.

>>>
>>> That was already pointed out to them.
>>>
>>> The lack of a comma should have resulted in a syntax error, which makes
>>> me believe, unless they modified the content before posting, that they may
>>> be modifying a different file to what is being read.
>>>
>>> I would like to see them, instead of changing DATABASES yet again, is to
>>> add at the very end of their settings.py file, the lines:
>>>
>>>   print __file__
>>>   print 'DATABASES', DATABASES
>>>
>>> This will prove two things. First that the file is being read as the
>>> output from this should show on stdout when running runserver or syncdb.
>>> Second, will show what Python is seeing DATABASES as being set to.
>>>
>>> if it doesn't show, then wrong file. If shows, but is different to what
>>> they believe they are setting it to, they could have multiple DATABASES
>>> entries in file.
>>>
>>> Graham
>>>
>>>  --
>>> You received this message because you are subscribed to the Google Groups
>>> "Django users" group.
>>> 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 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 subs

Re: Django Improper Configuration

[Graham Dumpleton]

On Monday, January 24, 2011 2:55:16 PM UTC+11, Graham Dumpleton wrote:
>
> Are you saying that those two print statements you were told to add are not 
> causing anything additional to be displayed on the screen when you run both 
> runserver and syncdb?
>
> This is why I asked you to provide the output again. You may not understand 
> what we are looking for. Don't care about what the error is at the point but 
> the information that those print statements should have output.
>

For the record, I would expect to see those print statements produce output 
at least twice. This is because settings.py actually gets imported multiple 
times. So, for example I see:

Grumpys-MacBook-Pro:mysite graham$ python manage.py runserver
Traceback (most recent call last):
  File "manage.py", line 2, in 
from django.core.management import execute_manager
ImportError: No module named django.core.management
Grumpys-MacBook-Pro:mysite graham$ source ../../bin/activate
(django-2)Grumpys-MacBook-Pro:mysite graham$ python manage.py runserver
/Library/WebServer/Sites/django-2/projects/mysite/settings.py
DATABASES {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME': 
'/Library/WebServer/Sites/django-2/db/database.db', 'HOST': '', 'USER': '', 
'PASSWORD': '', 'PORT': ''}}
/Library/WebServer/Sites/django-2/projects/mysite/../mysite/settings.pyc
DATABASES {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME': 
'/Library/WebServer/Sites/django-2/db/database.db', 'HOST': '', 'USER': '', 
'PASSWORD': '', 'PORT': ''}}
/Library/WebServer/Sites/django-2/projects/mysite/settings.pyc
DATABASES {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME': 
'/Library/WebServer/Sites/django-2/db/database.db', 'HOST': '', 'USER': '', 
'PASSWORD': '', 'PORT': ''}}
/Library/WebServer/Sites/django-2/projects/mysite/../mysite/settings.pyc
DATABASES {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME': 
'/Library/WebServer/Sites/django-2/db/database.db', 'HOST': '', 'USER': '', 
'PASSWORD': '', 'PORT': ''}}
Validating models...

0 errors found
Django version 1.3 beta 1, using settings 'mysite.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.


^C(django-2)Grumpys-MacBook-Pro:mysite graham$ python manage.py syncdb
/Library/WebServer/Sites/django-2/projects/mysite/settings.pyc
DATABASES {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME': 
'/Library/WebServer/Sites/django-2/db/database.db', 'HOST': '', 'USER': '', 
'PASSWORD': '', 'PORT': ''}}
/Library/WebServer/Sites/django-2/projects/mysite/../mysite/settings.pyc
DATABASES {'default': {'ENGINE': 'django.db.backends.sqlite3', 'NAME': 
'/Library/WebServer/Sites/django-2/db/database.db', 'HOST': '', 'USER': '', 
'PASSWORD': '', 'PORT': ''}}
Creating tables ...
Installing custom SQL ...
Installing indexes ...
No fixtures found.

Don't get me started on the multiple imports of settings.py file. :-(

Graham
 

On Monday, January 24, 2011 2:48:50 PM UTC+11, Kimberly wrote:
>>
>> I've provided the full errors in the post, it is there. ( same errors as 
>> I've faced prior to adding the print __file__ and 'DATABASES', DATABASES) as 
>> I'm encountering the same after I've copied and paste the print inside the 
>> settings.py file at the end)
>>
>> On Sun, Jan 23, 2011 at 9:40 PM, Graham Dumpleton wrote:
>>
>>> That is two underscores, followed by 'file' followed by two underscores. 
>>> Not just a single underscore.
>>>
>>> Please try and cut and paste out we give to use and vice versa. In other 
>>> words, provide complete output showing full errors and tracebacks. Such 
>>> information may be meaningful to use even if you think it isn't.
>>>
>>> Graham
>>>
>>>
>>> On Monday, January 24, 2011 2:35:06 PM UTC+11, Kimberly wrote:
>>>
 it says that the _file_ is not defined. 

 On Sun, Jan 23, 2011 at 9:28 PM, Graham Dumpleton wrote:

>
>
> On Monday, January 24, 2011 2:19:09 PM UTC+11, Steven Elliott Jr wrote:
>>
>> Copy and Paste the following to replace your entire DATABASES tuple:
>>
>> DATABASES = {
>> 'default': {
>> 'ENGINE': 'django.db.backends.sqlite3', 
>> 'NAME': 'database.db', 
>> 'USER': '',   
>> 'PASSWORD': '',   
>> 'HOST': '',   
>> 'PORT': '',   
>> }
>> }
>>
>> it looks like in your configuration you are also missing a comma after 
>> the name of the database. Remember you must include that comma because 
>> this 
>> is a tuple.
>>
>
> That was already pointed out to them.
>
> The lack of a comma should have resulted in a syntax error, which makes 
> me believe, unless they modified the content before posting, that they 
> may 
> be modifying a different file to what is being read.
>
> I would like to see them, instead of chan

Re: Django Improper Configuration

[Steven Elliott Jr]

Just curious if you've done a python tutorial yet? It's hard to really 
understand Django well unless you have at least some working knowledge of 
python. You will most definitely struggle later on when things become more 
complicated with your app. The framework is great for repetitive tasks but 
you're going to need to know how to write python code if you're to get 
anywhere. 

It's definitely possible to learn both at the same time but I'd read through, 
and work through a few python tutorials first then come back to Django. 

I know this is probably not what you'd like to hear and it's just my two cents 
so... 

Anyway, keep posting and we will try to help. 

-Steven

On Jan 23, 2011, at 10:40 PM, Graham Dumpleton  
wrote:

> That is two underscores, followed by 'file' followed by two underscores. Not 
> just a single underscore.
> 
> Please try and cut and paste out we give to use and vice versa. In other 
> words, provide complete output showing full errors and tracebacks. Such 
> information may be meaningful to use even if you think it isn't.
> 
> Graham
> 
> On Monday, January 24, 2011 2:35:06 PM UTC+11, Kimberly wrote:
> it says that the _file_ is not defined. 
> 
> On Sun, Jan 23, 2011 at 9:28 PM, Graham Dumpleton  
> wrote:
> 
> 
> On Monday, January 24, 2011 2:19:09 PM UTC+11, Steven Elliott Jr wrote:
> Copy and Paste the following to replace your entire DATABASES tuple:
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.sqlite3', 
> 'NAME': 'database.db', 
> 'USER': '',   
> 'PASSWORD': '',   
> 'HOST': '',   
> 'PORT': '',   
> }
> }
> 
> it looks like in your configuration you are also missing a comma after the 
> name of the database. Remember you must include that comma because this is a 
> tuple.
> 
> 
> That was already pointed out to them.
> 
> The lack of a comma should have resulted in a syntax error, which makes me 
> believe, unless they modified the content before posting, that they may be 
> modifying a different file to what is being read.
> 
> I would like to see them, instead of changing DATABASES yet again, is to add 
> at the very end of their settings.py file, the lines:
> 
>   print __file__
>   print 'DATABASES', DATABASES
> 
> This will prove two things. First that the file is being read as the output 
> from this should show on stdout when running runserver or syncdb. Second, 
> will show what Python is seeing DATABASES as being set to.
> 
> if it doesn't show, then wrong file. If shows, but is different to what they 
> believe they are setting it to, they could have multiple DATABASES entries in 
> file.
> 
> Graham
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> 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 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: Django Improper Configuration

[Graham Dumpleton]

Are you saying that those two print statements you were told to add are not 
causing anything additional to be displayed on the screen when you run both 
runserver and syncdb?

This is why I asked you to provide the output again. You may not understand 
what we are looking for. Don't care about what the error is at the point but 
the information that those print statements should have output.

Graham

On Monday, January 24, 2011 2:48:50 PM UTC+11, Kimberly wrote:
>
> I've provided the full errors in the post, it is there. ( same errors as 
> I've faced prior to adding the print __file__ and 'DATABASES', DATABASES) as 
> I'm encountering the same after I've copied and paste the print inside the 
> settings.py file at the end)
>
> On Sun, Jan 23, 2011 at 9:40 PM, Graham Dumpleton 
> wrote:
>
>> That is two underscores, followed by 'file' followed by two underscores. 
>> Not just a single underscore.
>>
>> Please try and cut and paste out we give to use and vice versa. In other 
>> words, provide complete output showing full errors and tracebacks. Such 
>> information may be meaningful to use even if you think it isn't.
>>
>> Graham
>>
>>
>> On Monday, January 24, 2011 2:35:06 PM UTC+11, Kimberly wrote:
>>
>>> it says that the _file_ is not defined. 
>>>
>>> On Sun, Jan 23, 2011 at 9:28 PM, Graham Dumpleton wrote:
>>>


 On Monday, January 24, 2011 2:19:09 PM UTC+11, Steven Elliott Jr wrote:
>
> Copy and Paste the following to replace your entire DATABASES tuple:
>
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.sqlite3', 
> 'NAME': 'database.db', 
> 'USER': '',   
> 'PASSWORD': '',   
> 'HOST': '',   
> 'PORT': '',   
> }
> }
>
> it looks like in your configuration you are also missing a comma after 
> the name of the database. Remember you must include that comma because 
> this 
> is a tuple.
>

 That was already pointed out to them.

 The lack of a comma should have resulted in a syntax error, which makes 
 me believe, unless they modified the content before posting, that they may 
 be modifying a different file to what is being read.

 I would like to see them, instead of changing DATABASES yet again, is to 
 add at the very end of their settings.py file, the lines:

   print __file__
   print 'DATABASES', DATABASES

 This will prove two things. First that the file is being read as the 
 output from this should show on stdout when running runserver or syncdb. 
 Second, will show what Python is seeing DATABASES as being set to.

 if it doesn't show, then wrong file. If shows, but is different to what 
 they believe they are setting it to, they could have multiple DATABASES 
 entries in file.

 Graham

  -- 
 You received this message because you are subscribed to the Google 
 Groups "Django users" group.
 To post to this group, send email to djan...@googlegroups.com.
 To unsubscribe from this group, send email to 
 django-...@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...@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 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 Improper Configuration

[Kimberly Harvey]

I've provided the full errors in the post, it is there. ( same errors as
I've faced prior to adding the print __file__ and 'DATABASES', DATABASES) as
I'm encountering the same after I've copied and paste the print inside the
settings.py file at the end)

On Sun, Jan 23, 2011 at 9:40 PM, Graham Dumpleton <
graham.dumple...@gmail.com> wrote:

> That is two underscores, followed by 'file' followed by two underscores.
> Not just a single underscore.
>
> Please try and cut and paste out we give to use and vice versa. In other
> words, provide complete output showing full errors and tracebacks. Such
> information may be meaningful to use even if you think it isn't.
>
> Graham
>
>
> On Monday, January 24, 2011 2:35:06 PM UTC+11, Kimberly wrote:
>
>> it says that the _file_ is not defined.
>>
>> On Sun, Jan 23, 2011 at 9:28 PM, Graham Dumpleton 
>> wrote:
>>
>>>
>>>
>>> On Monday, January 24, 2011 2:19:09 PM UTC+11, Steven Elliott Jr wrote:

 Copy and Paste the following to replace your entire DATABASES tuple:

 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.sqlite3',
 'NAME': 'database.db',
 'USER': '',
 'PASSWORD': '',
 'HOST': '',
 'PORT': '',
 }
 }

 it looks like in your configuration you are also missing a comma after
 the name of the database. Remember you must include that comma because this
 is a tuple.

>>>
>>> That was already pointed out to them.
>>>
>>> The lack of a comma should have resulted in a syntax error, which makes
>>> me believe, unless they modified the content before posting, that they may
>>> be modifying a different file to what is being read.
>>>
>>> I would like to see them, instead of changing DATABASES yet again, is to
>>> add at the very end of their settings.py file, the lines:
>>>
>>>   print __file__
>>>   print 'DATABASES', DATABASES
>>>
>>> This will prove two things. First that the file is being read as the
>>> output from this should show on stdout when running runserver or syncdb.
>>> Second, will show what Python is seeing DATABASES as being set to.
>>>
>>> if it doesn't show, then wrong file. If shows, but is different to what
>>> they believe they are setting it to, they could have multiple DATABASES
>>> entries in file.
>>>
>>> Graham
>>>
>>>  --
>>> You received this message because you are subscribed to the Google Groups
>>> "Django users" group.
>>> 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 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: Django Improper Configuration

[Graham Dumpleton]

That is two underscores, followed by 'file' followed by two underscores. Not 
just a single underscore.

Please try and cut and paste out we give to use and vice versa. In other 
words, provide complete output showing full errors and tracebacks. Such 
information may be meaningful to use even if you think it isn't.

Graham

On Monday, January 24, 2011 2:35:06 PM UTC+11, Kimberly wrote:
>
> it says that the _file_ is not defined. 
>
> On Sun, Jan 23, 2011 at 9:28 PM, Graham Dumpleton 
> wrote:
>
>>
>>
>> On Monday, January 24, 2011 2:19:09 PM UTC+11, Steven Elliott Jr wrote:
>>>
>>> Copy and Paste the following to replace your entire DATABASES tuple:
>>>
>>> DATABASES = {
>>> 'default': {
>>> 'ENGINE': 'django.db.backends.sqlite3', 
>>> 'NAME': 'database.db', 
>>> 'USER': '',   
>>> 'PASSWORD': '',   
>>> 'HOST': '',   
>>> 'PORT': '',   
>>> }
>>> }
>>>
>>> it looks like in your configuration you are also missing a comma after 
>>> the name of the database. Remember you must include that comma because this 
>>> is a tuple.
>>>
>>
>> That was already pointed out to them.
>>
>> The lack of a comma should have resulted in a syntax error, which makes me 
>> believe, unless they modified the content before posting, that they may be 
>> modifying a different file to what is being read.
>>
>> I would like to see them, instead of changing DATABASES yet again, is to 
>> add at the very end of their settings.py file, the lines:
>>
>>   print __file__
>>   print 'DATABASES', DATABASES
>>
>> This will prove two things. First that the file is being read as the 
>> output from this should show on stdout when running runserver or syncdb. 
>> Second, will show what Python is seeing DATABASES as being set to.
>>
>> if it doesn't show, then wrong file. If shows, but is different to what 
>> they believe they are setting it to, they could have multiple DATABASES 
>> entries in file.
>>
>> Graham
>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> 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 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 Improper Configuration

[Kimberly Harvey]

it says that the _file_ is not defined.

On Sun, Jan 23, 2011 at 9:28 PM, Graham Dumpleton <
graham.dumple...@gmail.com> wrote:

>
>
> On Monday, January 24, 2011 2:19:09 PM UTC+11, Steven Elliott Jr wrote:
>>
>> Copy and Paste the following to replace your entire DATABASES tuple:
>>
>> DATABASES = {
>> 'default': {
>> 'ENGINE': 'django.db.backends.sqlite3',
>> 'NAME': 'database.db',
>> 'USER': '',
>> 'PASSWORD': '',
>> 'HOST': '',
>> 'PORT': '',
>> }
>> }
>>
>> it looks like in your configuration you are also missing a comma after the
>> name of the database. Remember you must include that comma because this is a
>> tuple.
>>
>
> That was already pointed out to them.
>
> The lack of a comma should have resulted in a syntax error, which makes me
> believe, unless they modified the content before posting, that they may be
> modifying a different file to what is being read.
>
> I would like to see them, instead of changing DATABASES yet again, is to
> add at the very end of their settings.py file, the lines:
>
>   print __file__
>   print 'DATABASES', DATABASES
>
> This will prove two things. First that the file is being read as the output
> from this should show on stdout when running runserver or syncdb. Second,
> will show what Python is seeing DATABASES as being set to.
>
> if it doesn't show, then wrong file. If shows, but is different to what
> they believe they are setting it to, they could have multiple DATABASES
> entries in file.
>
> Graham
>
>  --
> 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: Django Improper Configuration

[Steven Elliott]

> That was already pointed out to them.

You're right, sorry my bad -- I just got to my computer and read the thread 
rather than just using my phone.

> The lack of a comma should have resulted in a syntax error, which makes me 
> believe, unless they modified the content before posting, that they may be 
> modifying a different file to what is being read.
> 
> I would like to see them, instead of changing DATABASES yet again, is to add 
> at the very end of their settings.py file, the lines:
> 
>   print __file__
>   print 'DATABASES', DATABASES
> 
> This will prove two things. First that the file is being read as the output 
> from this should show on stdout when running runserver or syncdb. Second, 
> will show what Python is seeing DATABASES as being set to.
> 
> if it doesn't show, then wrong file. If shows, but is different to what they 
> believe they are setting it to, they could have multiple DATABASES entries in 
> file.

Yes, this is excellent advice -- post the output you get from the terminal 
after you've run it. 


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

[Kimberly Harvey]

I am using pico editior and I've been saving the work by using the control
X.

On Sun, Jan 23, 2011 at 9:25 PM, Steven Elliott  wrote:

> Also, what editor are you using? if its not an IDE-type thing remember to
> save your work in the editor. If you are coming from the Windows programming
> world generally your programs will save when you build and run something in
> the IDE. If you're using just an editor like Emacs, Vim, Gedit, Kate, or
> whatever it is you must remember to save your work after you've made and
> edit.
>
>
> --
> 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: Django Improper Configuration

[Graham Dumpleton]

On Monday, January 24, 2011 2:19:09 PM UTC+11, Steven Elliott Jr wrote:
>
> Copy and Paste the following to replace your entire DATABASES tuple:
>
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.sqlite3', 
> 'NAME': 'database.db', 
> 'USER': '',   
> 'PASSWORD': '',   
> 'HOST': '',   
> 'PORT': '',   
> }
> }
>
> it looks like in your configuration you are also missing a comma after the 
> name of the database. Remember you must include that comma because this is a 
> tuple.
>

That was already pointed out to them.

The lack of a comma should have resulted in a syntax error, which makes me 
believe, unless they modified the content before posting, that they may be 
modifying a different file to what is being read.

I would like to see them, instead of changing DATABASES yet again, is to add 
at the very end of their settings.py file, the lines:

  print __file__
  print 'DATABASES', DATABASES

This will prove two things. First that the file is being read as the output 
from this should show on stdout when running runserver or syncdb. Second, 
will show what Python is seeing DATABASES as being set to.

if it doesn't show, then wrong file. If shows, but is different to what they 
believe they are setting it to, they could have multiple DATABASES entries 
in file.

Graham

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

[Kimberly Harvey]

It is not working at all, still facing the same configuration problem
(ENGINE IS NOT SET).

On Sun, Jan 23, 2011 at 9:19 PM, Steven Elliott  wrote:

> Copy and Paste the following to replace your entire DATABASES tuple:
>
> DATABASES = {
>'default': {
>'ENGINE': 'django.db.backends.sqlite3',
> 'NAME': 'database.db',
>'USER': '',
>'PASSWORD': '',
>'HOST': '',
>'PORT': '',
>}
> }
>
> it looks like in your configuration you are also missing a comma after the
> name of the database. Remember you must include that comma because this is a
> tuple.
>
>
>
> --
> 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: Django Improper Configuration

[Steven Elliott]

Also, what editor are you using? if its not an IDE-type thing remember to save 
your work in the editor. If you are coming from the Windows programming world 
generally your programs will save when you build and run something in the IDE. 
If you're using just an editor like Emacs, Vim, Gedit, Kate, or whatever it is 
you must remember to save your work after you've made and edit. 


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

[Steven Elliott]

Copy and Paste the following to replace your entire DATABASES tuple:

DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3', 
'NAME': 'database.db', 
'USER': '', 
'PASSWORD': '', 
'HOST': '', 
'PORT': '', 
}
}

it looks like in your configuration you are also missing a comma after the name 
of the database. Remember you must include that comma because this is a tuple.



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

[Kimberly Harvey]

That doesn't work for me ( very very strange), that why I am very confused
on what is going on with the database itself.

On Sun, Jan 23, 2011 at 8:55 PM, Steven Elliott Jr  wrote:

> I remember that the one time I tried sqlite it complained until I put a .db
> suffix on the name of my database. If you do not specify the full path and
> just specify a name, then it will just create the database file in your
> project's root directory.
>
> So, under name just put:
>
> 'NAME' : 'database.db',
>
> And see if that works.
>
> -Steve
> Sent from my iPhone
>
>
> On Jan 23, 2011, at 9:48 PM, Graham Dumpleton 
> wrote:
>
>
>
> On Monday, January 24, 2011 1:36:10 PM UTC+11, Kimberly wrote:
>>
>> username@debian:~/wikicamps$ python manage.py runserver
>> Validating models
>> 0 errors found
>>
>> Django version 1.2.4, using settings 'wikicamp.settings'
>> Development server is running at 
>> http://127.0.0.1:8000/
>> Quit the server with CONTROL-C.
>>
>> It runs fine, but yet I faced problem with the database ENGINE.
>>
>
> Where are you seeing that error because it isn't in what you quote above?
>
> If it is in the browser, paste the Python exception details and traceback
> from the browser. Not everything, just the exception message and traceback
> will do.
>
> In other words, we need to see the actual context in which the real error
> message is displayed and the exact wording of the error message and the
> location.
>
> Graham
>
>
>> On Sun, Jan 23, 2011 at 8:19 PM, Graham Dumpleton 
>> wrote:
>>
>>> Provide  the full error including any Python traceback so we can see
>>> where the error is occurring. If running manage.py runserver, easiest thing
>>> to do is to provide the whole output from running the command.
>>>
>>> Graham
>>>
>>> On Monday, January 24, 2011 1:11:47 PM UTC+11, Kimberly wrote:
>>>
 Still doesn't work. But thank you for trying to help me. It keep giving
 me the same ENGINE configuration that it is not set.

 On Sun, Jan 23, 2011 at 8:05 PM, Graham Dumpleton 
 wrote:

>
>
> On Monday, January 24, 2011 12:42:57 PM UTC+11, Kimberly wrote:
>>
>> Sorry about that... here is what I have in the settings.py ( similiar
>> to what you showed, but mine is abit different in the NAME section):
>>
>> DATABASES = {
>> 'default': {
>> 'ENGINE': 'django.db.backends.sqlite3', # Add
>> 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
>> 'NAME':  'home/username/directory/database'  #
>> Or path to database file if using sqlite3.
>>
>
> You deleted the comma after the string and missing leading slash on
> path. Try:
>
> 'NAME':  '/home/username/directory/database',
>  # Or path to database file if using sqlite3.
>
> Not sure how you didn't just get a syntax error.
>
> Graham
>
>
>> 'USER': '',  # Not used with sqlite3.
>> 'PASSWORD': '',  # Not used with sqlite3.
>> 'HOST': '',  # Set to empty string for
>> localhost. Not used with sqlite3.
>> 'PORT': '',  # Set to empty string for
>> default. Not used with sqlite3.
>> }
>> }
>>
>> Inside the settings.py file, in the template_dirs section, there's a
>> line says os.path.join(os.path.dirname(_file_), 'templates')
>>
>> If I comment that, then there's a error saying it doesn't recognize
>> _file_. I commented that line, then it says that the setting ENGINE has 
>> not
>> been set.
>>
>>
>> On Sun, Jan 23, 2011 at 7:32 PM, Graham Dumpleton 
>> wrote:
>>
>>>  Rather than have us guess what is in your settings file, post that
>>> whole section. For example:
>>>
>>> DATABASES = {
>>> 'default': {
>>> 'ENGINE': 'django.db.backends.sqlite3', # Add
>>> 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
>>> 'NAME': os.path.join(ENVIRON_ROOT, 'db', 'database.db'),
>>>  # Or path to database file if using sqlite3.
>>> 'USER': '',  # Not used with sqlite3.
>>> 'PASSWORD': '',  # Not used with sqlite3.
>>> 'HOST': '',  # Set to empty string for
>>> localhost. Not used with sqlite3.
>>> 'PORT': '',  # Set to empty string for
>>> default. Not used with sqlite3.
>>> }
>>> }
>>>
>>> This will allow everyone to see if you have mucked up some other part
>>> of the settings.
>>>
>>> Graham
>>>
>>> On Monday, January 24, 2011 11:39:02 AM UTC+11, Kimberly wrote:
>>>
  I've used the tutorials and it doesn't work. I've done exactly
 what the tutorial says, and it keeps saying that the ENGINE has not 
>

Re: Django Improper Configuration

[Kimberly Harvey]

The error that I am seeing is in the shell/ the terminal. I am unable to
paste the exception problems on here. But I've typed it... look below

After I've ran the python manage.py runserver, there was NO errors. But when
I try to use, python manage.py syncdb, it showed errors/exceptions:

Traceback ( most recent call last):
 File "manage.py", line 11, in 
execute_manager(settings)
File
"/usr/lib/python2.5/site-packages/django/core/management/_init_.py", line
438, in execute manager
File
"/usr/lib/python2.5/site-packages/django/core/management/_init_.py", line
379, in execute
  self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/lib/python2.5/site-packages/django/core/management/base.py",
line 191, in run_from_argv
self.exectured(*args, **options._dict_)
File "/usr/lib/python2.5/site-packages/django/core/management/base.py", line
220, in execute
output = self.handle(*args, **options)
File "/usr/lib/python2.5/site-packages/django/core/management/base.py", line
351, in handle
   return self.handle_noargs(**options)
File
"/usr/lib/python2.5/site-packages/django/core/management/commands/syncdb.py",
line 52, in handle_noargs
cursor = connection.cursor()
File "/usr/lib/python2.5/site-packages/django/db/backends/dummy/base.py",
line 15, in complain
raise ImproperlyConfigured("You hav
en't set the database ENGINE setting yet.")
On Sun, Jan 23, 2011 at 8:48 PM, Graham Dumpleton <
graham.dumple...@gmail.com> wrote:

>
>
> On Monday, January 24, 2011 1:36:10 PM UTC+11, Kimberly wrote:
>>
>> username@debian:~/wikicamps$ python manage.py runserver
>> Validating models
>> 0 errors found
>>
>> Django version 1.2.4, using settings 'wikicamp.settings'
>> Development server is running at http://127.0.0.1:8000/
>> Quit the server with CONTROL-C.
>>
>> It runs fine, but yet I faced problem with the database ENGINE.
>>
>
> Where are you seeing that error because it isn't in what you quote above?
>
> If it is in the browser, paste the Python exception details and traceback
> from the browser. Not everything, just the exception message and traceback
> will do.
>
> In other words, we need to see the actual context in which the real error
> message is displayed and the exact wording of the error message and the
> location.
>
> Graham
>
>
>> On Sun, Jan 23, 2011 at 8:19 PM, Graham Dumpleton 
>> wrote:
>>
>>> Provide  the full error including any Python traceback so we can see
>>> where the error is occurring. If running manage.py runserver, easiest thing
>>> to do is to provide the whole output from running the command.
>>>
>>> Graham
>>>
>>> On Monday, January 24, 2011 1:11:47 PM UTC+11, Kimberly wrote:
>>>
 Still doesn't work. But thank you for trying to help me. It keep giving
 me the same ENGINE configuration that it is not set.

 On Sun, Jan 23, 2011 at 8:05 PM, Graham Dumpleton 
 wrote:

>
>
> On Monday, January 24, 2011 12:42:57 PM UTC+11, Kimberly wrote:
>>
>> Sorry about that... here is what I have in the settings.py ( similiar
>> to what you showed, but mine is abit different in the NAME section):
>>
>> DATABASES = {
>> 'default': {
>> 'ENGINE': 'django.db.backends.sqlite3', # Add
>> 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
>> 'NAME':  'home/username/directory/database'  #
>> Or path to database file if using sqlite3.
>>
>
> You deleted the comma after the string and missing leading slash on
> path. Try:
>
> 'NAME':  '/home/username/directory/database',
>  # Or path to database file if using sqlite3.
>
> Not sure how you didn't just get a syntax error.
>
> Graham
>
>
>> 'USER': '',  # Not used with sqlite3.
>> 'PASSWORD': '',  # Not used with sqlite3.
>> 'HOST': '',  # Set to empty string for
>> localhost. Not used with sqlite3.
>> 'PORT': '',  # Set to empty string for
>> default. Not used with sqlite3.
>> }
>> }
>>
>> Inside the settings.py file, in the template_dirs section, there's a
>> line says os.path.join(os.path.dirname(_file_), 'templates')
>>
>> If I comment that, then there's a error saying it doesn't recognize
>> _file_. I commented that line, then it says that the setting ENGINE has 
>> not
>> been set.
>>
>>
>> On Sun, Jan 23, 2011 at 7:32 PM, Graham Dumpleton 
>> wrote:
>>
>>>  Rather than have us guess what is in your settings file, post that
>>> whole section. For example:
>>>
>>> DATABASES = {
>>> 'default': {
>>> 'ENGINE': 'django.db.backends.sqlite3', # Add
>>> 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
>>> 'NAME': os.path.join(ENVIRON_ROOT, 'db', 'database.db'),
>>> 

Re: Django Improper Configuration

[Steven Elliott Jr]

I remember that the one time I tried sqlite it complained until I put a .db 
suffix on the name of my database. If you do not specify the full path and just 
specify a name, then it will just create the database file in your project's 
root directory. 

So, under name just put:

'NAME' : 'database.db',

And see if that works. 

-Steve
Sent from my iPhone 


On Jan 23, 2011, at 9:48 PM, Graham Dumpleton  
wrote:

> 
> 
> On Monday, January 24, 2011 1:36:10 PM UTC+11, Kimberly wrote:
> username@debian:~/wikicamps$ python manage.py runserver
> Validating models
> 0 errors found
> 
> Django version 1.2.4, using settings 'wikicamp.settings'
> Development server is running at http://127.0.0.1:8000/
> Quit the server with CONTROL-C.
> 
> It runs fine, but yet I faced problem with the database ENGINE. 
> 
> Where are you seeing that error because it isn't in what you quote above?
> 
> If it is in the browser, paste the Python exception details and traceback 
> from the browser. Not everything, just the exception message and traceback 
> will do.
> 
> In other words, we need to see the actual context in which the real error 
> message is displayed and the exact wording of the error message and the 
> location.
> 
> Graham
>  
> On Sun, Jan 23, 2011 at 8:19 PM, Graham Dumpleton  
> wrote:
> Provide  the full error including any Python traceback so we can see where 
> the error is occurring. If running manage.py runserver, easiest thing to do 
> is to provide the whole output from running the command.
> 
> Graham
> 
> On Monday, January 24, 2011 1:11:47 PM UTC+11, Kimberly wrote:
> Still doesn't work. But thank you for trying to help me. It keep giving me 
> the same ENGINE configuration that it is not set.
> 
> On Sun, Jan 23, 2011 at 8:05 PM, Graham Dumpleton  wrote:
> 
> 
> On Monday, January 24, 2011 12:42:57 PM UTC+11, Kimberly wrote:
> Sorry about that... here is what I have in the settings.py ( similiar to what 
> you showed, but mine is abit different in the NAME section):
> 
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.sqlite3', # Add 'postgresql_psycopg2', 
> 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
> 'NAME':  'home/username/directory/database'  # Or 
> path to database file if using sqlite3.
> 
> You deleted the comma after the string and missing leading slash on path. Try:
> 
> 'NAME':  '/home/username/directory/database',  # Or 
> path to database file if using sqlite3.
> 
> Not sure how you didn't just get a syntax error.
> 
> Graham
>  
> 'USER': '',  # Not used with sqlite3.
> 'PASSWORD': '',  # Not used with sqlite3.
> 'HOST': '',  # Set to empty string for localhost. 
> Not used with sqlite3.
> 'PORT': '',  # Set to empty string for default. 
> Not used with sqlite3.
> }
> }
> 
> Inside the settings.py file, in the template_dirs section, there's a line 
> says os.path.join(os.path.dirname(_file_), 'templates')
> 
> If I comment that, then there's a error saying it doesn't recognize _file_. I 
> commented that line, then it says that the setting ENGINE has not been set.
> 
> 
> On Sun, Jan 23, 2011 at 7:32 PM, Graham Dumpleton  wrote:
> Rather than have us guess what is in your settings file, post that whole 
> section. For example:
> 
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.sqlite3', # Add 'postgresql_psycopg2', 
> 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
> 'NAME': os.path.join(ENVIRON_ROOT, 'db', 'database.db'),  
> # Or path to database file if using sqlite3.
> 'USER': '',  # Not used with sqlite3.
> 'PASSWORD': '',  # Not used with sqlite3.
> 'HOST': '',  # Set to empty string for localhost. 
> Not used with sqlite3.
> 'PORT': '',  # Set to empty string for default. 
> Not used with sqlite3.
> }
> }
> 
> This will allow everyone to see if you have mucked up some other part of the 
> settings.
> 
> Graham
> 
> On Monday, January 24, 2011 11:39:02 AM UTC+11, Kimberly wrote:
> I've used the tutorials and it doesn't work. I've done exactly what the 
> tutorial says, and it keeps saying that the ENGINE has not been set in the 
> setting. I am also using Django 1.2 or higher version.
> 
> On Sun, Jan 23, 2011 at 6:29 PM, Karen Tracey  wrote:
> On Sun, Jan 23, 2011 at 6:47 PM, Kimberly Harvey  wrote:
> it still doesn't work. I typed it like you've suggested and it keeps saying 
> that the database ENGINE has not been set.
> 
> 
> If you are using ENGINE by itself, you need to be using Django 1.2 or higher 
> and ENGINE is a key in the dictionary of settings for the default database, 
> not a single ENGINE line in settings.py. See: 
> 
> http://docs.djangoproject.com/en/dev/ref/settings/?from=olddocs#databases
> 
> for details. 
> 

Re: Django Improper Configuration

[Graham Dumpleton]

On Monday, January 24, 2011 1:36:10 PM UTC+11, Kimberly wrote:
>
> username@debian:~/wikicamps$ python manage.py runserver
> Validating models
> 0 errors found
>
> Django version 1.2.4, using settings 'wikicamp.settings'
> Development server is running at http://127.0.0.1:8000/
> Quit the server with CONTROL-C.
>
> It runs fine, but yet I faced problem with the database ENGINE. 
>

Where are you seeing that error because it isn't in what you quote above?

If it is in the browser, paste the Python exception details and traceback 
from the browser. Not everything, just the exception message and traceback 
will do.

In other words, we need to see the actual context in which the real error 
message is displayed and the exact wording of the error message and the 
location.

Graham
 

> On Sun, Jan 23, 2011 at 8:19 PM, Graham Dumpleton 
> wrote:
>
>> Provide  the full error including any Python traceback so we can see where 
>> the error is occurring. If running manage.py runserver, easiest thing to do 
>> is to provide the whole output from running the command.
>>
>> Graham
>>
>> On Monday, January 24, 2011 1:11:47 PM UTC+11, Kimberly wrote:
>>
>>> Still doesn't work. But thank you for trying to help me. It keep giving 
>>> me the same ENGINE configuration that it is not set.
>>>
>>> On Sun, Jan 23, 2011 at 8:05 PM, Graham Dumpleton wrote:
>>>


 On Monday, January 24, 2011 12:42:57 PM UTC+11, Kimberly wrote:
>
> Sorry about that... here is what I have in the settings.py ( similiar 
> to what you showed, but mine is abit different in the NAME section):
>
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.sqlite3', # Add 
> 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
> 'NAME':  'home/username/directory/database'  # 
> Or path to database file if using sqlite3.
>

 You deleted the comma after the string and missing leading slash on 
 path. Try:

 'NAME':  '/home/username/directory/database',  # 
 Or path to database file if using sqlite3.

 Not sure how you didn't just get a syntax error.

 Graham
  

> 'USER': '',  # Not used with sqlite3.
> 'PASSWORD': '',  # Not used with sqlite3.
> 'HOST': '',  # Set to empty string for 
> localhost. Not used with sqlite3.
> 'PORT': '',  # Set to empty string for 
> default. Not used with sqlite3.
> }
> }
>
> Inside the settings.py file, in the template_dirs section, there's a 
> line says os.path.join(os.path.dirname(_file_), 'templates')
>
> If I comment that, then there's a error saying it doesn't recognize 
> _file_. I commented that line, then it says that the setting ENGINE has 
> not 
> been set.
>
>
> On Sun, Jan 23, 2011 at 7:32 PM, Graham Dumpleton 
> wrote:
>
>>  Rather than have us guess what is in your settings file, post that 
>> whole section. For example:
>>
>> DATABASES = {
>> 'default': {
>> 'ENGINE': 'django.db.backends.sqlite3', # Add 
>> 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
>> 'NAME': os.path.join(ENVIRON_ROOT, 'db', 'database.db'),   
>># Or path to database file if using sqlite3.
>> 'USER': '',  # Not used with sqlite3.
>> 'PASSWORD': '',  # Not used with sqlite3.
>> 'HOST': '',  # Set to empty string for 
>> localhost. Not used with sqlite3.
>> 'PORT': '',  # Set to empty string for 
>> default. Not used with sqlite3.
>> }
>> }
>>
>> This will allow everyone to see if you have mucked up some other part 
>> of the settings.
>>
>> Graham
>>
>> On Monday, January 24, 2011 11:39:02 AM UTC+11, Kimberly wrote:
>>
>>>  I've used the tutorials and it doesn't work. I've done exactly what 
>>> the tutorial says, and it keeps saying that the ENGINE has not been set 
>>> in 
>>> the setting. I am also using Django 1.2 or higher version.
>>>
>>> On Sun, Jan 23, 2011 at 6:29 PM, Karen Tracey wrote:
>>>
   On Sun, Jan 23, 2011 at 6:47 PM, Kimberly Harvey <
 kha...@gmail.com> wrote:

> it still doesn't work. I typed it like you've suggested and it 
> keeps saying that the database ENGINE has not been set.
>
>
 If you are using ENGINE by itself, you need to be using Django 1.2 
 or higher and ENGINE is a key in the dictionary of settings for the 
 default 
 database, not a single ENGINE line in settings.py. See: 


 http://docs.djangoproject.com/en/dev/ref/s

Re: Django Improper Configuration

[Kimberly Harvey]

username@debian:~/wikicamps$ python manage.py runserver
Validating models
0 errors found

Django version 1.2.4, using settings 'wikicamp.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

It runs fine, but yet I faced problem with the database ENGINE.
On Sun, Jan 23, 2011 at 8:19 PM, Graham Dumpleton <
graham.dumple...@gmail.com> wrote:

> Provide  the full error including any Python traceback so we can see where
> the error is occurring. If running manage.py runserver, easiest thing to do
> is to provide the whole output from running the command.
>
> Graham
>
> On Monday, January 24, 2011 1:11:47 PM UTC+11, Kimberly wrote:
>
>> Still doesn't work. But thank you for trying to help me. It keep giving me
>> the same ENGINE configuration that it is not set.
>>
>> On Sun, Jan 23, 2011 at 8:05 PM, Graham Dumpleton 
>> wrote:
>>
>>>
>>>
>>> On Monday, January 24, 2011 12:42:57 PM UTC+11, Kimberly wrote:

 Sorry about that... here is what I have in the settings.py ( similiar to
 what you showed, but mine is abit different in the NAME section):

 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.sqlite3', # Add
 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
 'NAME':  'home/username/directory/database'  #
 Or path to database file if using sqlite3.

>>>
>>> You deleted the comma after the string and missing leading slash on path.
>>> Try:
>>>
>>> 'NAME':  '/home/username/directory/database',  #
>>> Or path to database file if using sqlite3.
>>>
>>> Not sure how you didn't just get a syntax error.
>>>
>>> Graham
>>>
>>>
 'USER': '',  # Not used with sqlite3.
 'PASSWORD': '',  # Not used with sqlite3.
 'HOST': '',  # Set to empty string for
 localhost. Not used with sqlite3.
 'PORT': '',  # Set to empty string for
 default. Not used with sqlite3.
 }
 }

 Inside the settings.py file, in the template_dirs section, there's a
 line says os.path.join(os.path.dirname(_file_), 'templates')

 If I comment that, then there's a error saying it doesn't recognize
 _file_. I commented that line, then it says that the setting ENGINE has not
 been set.


 On Sun, Jan 23, 2011 at 7:32 PM, Graham Dumpleton 
 wrote:

>  Rather than have us guess what is in your settings file, post that
> whole section. For example:
>
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.sqlite3', # Add
> 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
> 'NAME': os.path.join(ENVIRON_ROOT, 'db', 'database.db'),
># Or path to database file if using sqlite3.
> 'USER': '',  # Not used with sqlite3.
> 'PASSWORD': '',  # Not used with sqlite3.
> 'HOST': '',  # Set to empty string for
> localhost. Not used with sqlite3.
> 'PORT': '',  # Set to empty string for
> default. Not used with sqlite3.
> }
> }
>
> This will allow everyone to see if you have mucked up some other part
> of the settings.
>
> Graham
>
> On Monday, January 24, 2011 11:39:02 AM UTC+11, Kimberly wrote:
>
>>  I've used the tutorials and it doesn't work. I've done exactly what
>> the tutorial says, and it keeps saying that the ENGINE has not been set 
>> in
>> the setting. I am also using Django 1.2 or higher version.
>>
>> On Sun, Jan 23, 2011 at 6:29 PM, Karen Tracey wrote:
>>
>>>  On Sun, Jan 23, 2011 at 6:47 PM, Kimberly Harvey 
>>> wrote:
>>>
 it still doesn't work. I typed it like you've suggested and it keeps
 saying that the database ENGINE has not been set.


>>> If you are using ENGINE by itself, you need to be using Django 1.2 or
>>> higher and ENGINE is a key in the dictionary of settings for the default
>>> database, not a single ENGINE line in settings.py. See:
>>>
>>>
>>> http://docs.djangoproject.com/en/dev/ref/settings/?from=olddocs#databases
>>>
>>> for details.
>>>
>>> If you are using a Django version prior to 1.2, the setting you
>>> should be using is DATABASE_ENGINE (see
>>> http://docs.djangoproject.com/en/1.1/ref/settings/#database-engine),
>>> not just ENGINE.
>>>
>>> Karen
>>> --
>>> http://tracey.org/kmt/
>>>
>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django users" group.
>>> To post to this group, send email to dja...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> djang...@googlegrou

Re: 32-bit integers IP address to 4-octet IP address

[aledr]

>From the Django docs[1]:

"values() takes optional positional arguments, *fields, which specify
field names to which the SELECT should be limited. If you specify the
fields, each dictionary will contain only the field keys/values for
the fields you specify. If you don't specify the fields, each
dictionary will contain a key and value for every field in the
database table."

So, when you try "ip = Iphdr.objects.values("ip_src")" you are not
getting the 32 bit integer you want.

[1]: http://docs.djangoproject.com/en/dev/ref/models/querysets/

On Sun, Jan 23, 2011 at 8:36 PM, phil...@bailey.st  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I aledr,
>
> thanks for your reply,
>
>
> I've added the  socket.inet_ntoa to my  view.py
>
> #view.py
> from django.http import HttpResponse
> import socket
> from snort.models import  Iphdr
>
>
> def snort(request):
>
>    ip = Iphdr.objects.values("ip_src")
>    return socket.inet_ntoa(ip)
>
>
> after opening the web page I get this error bac
>
>
>
>
>
> Request Method:         GET
> Request URL:    http://192.168.1.5:8080/
> Django Version:         1.3 beta 1
> Exception Type:         TypeError
> Exception Value:
>
> inet_aton() argument 1 must be string, not ValuesQuerySet
>
> Exception Location:     /home/user/django/app/../snort/views.py in snort,
> line 10
> Python Executable:      /usr/bin/python
> Python Version:         2.6.5
> Python Path:
>
> ['/home/crypto/django/snort',
>  '/usr/lib/python2.6',
>  '/usr/lib/python2.6/plat-linux2',
>  '/usr/lib/python2.6/lib-tk',
>  '/usr/lib/python2.6/lib-old',
>  '/usr/lib/python2.6/lib-dynload',
>  '/usr/lib/python2.6/dist-packages',
>  '/usr/lib/pymodules/python2.6',
>  '/usr/lib/pymodules/python2.6/gtk-2.0',
>  '/usr/lib/python2.6/dist-packages/wx-2.8-gtk2-unicode',
>  '/usr/local/lib/python2.6/dist-packages']
> ~
>
>
> What I'm doing wrong ?
>
> Thanks again,
>
> Phillip
>
>
>
> On 01/23/2011 07:18 PM, aledr wrote:
>> I guess socket.inet_ntoa is enough for what you need.
>>
>> On Sun, Jan 23, 2011 at 7:06 AM, Phillip Bailey  wrote:
>>
>>
>> Dear All,
>>
>> I've started playing around with Django in the last few days, and I'm
>> enjoying the speed
>> and the power of such framework. I'm writing a small application to
>> display and sort
>> ip addresses stored in a Postgresql database, right now I'm stuck with
>> 32-bit integers
>> IP address translated to 4-octet IP address .
>>
>> Here's the the class of the ip address.
>>
>> class Iphdr(models.Model):
>>    sid = models.IntegerField(primary_key=True)
>>    cid = models.BigIntegerField(primary_key=True)
>>    ip_src = models.BigIntegerField()
>>    ip_dst = models.BigIntegerField()
>>    ip_ver = models.SmallIntegerField()
>>    ip_hlen = models.SmallIntegerField()
>>    ip_tos = models.SmallIntegerField()
>>    ip_len = models.IntegerField()
>>    ip_id = models.IntegerField()
>>    ip_flags = models.SmallIntegerField()
>>    ip_off = models.IntegerField()
>>    ip_ttl = models.SmallIntegerField()
>>    ip_proto = models.SmallIntegerField()
>>    ip_csum = models.IntegerField()
>>    class Meta:
>>        db_table = u'iphdr'
>>
>>
>> As the IP addresses are stored in the database as unsigned 32-bit
>> integers, so when I
>> run  ip = Iphdr.objects.values("ip_src") the result is in 32-bit integers,
>>
>> {'ip_src': 3251031814L}{'ip_src': 3251031816L}{'ip_src': 3251031816L}
>> {'ip_src': 3251031816L}{'ip_src': 3251031814L}{'ip_src': 3251031816L}
>>
>> There's any elegant solution that can translate 32-bit integers to
>> 4-octet IP address (192.168.1.88) ?
>>
>> Thanks in advance.
>>
>> Phillip
>>>
> - --
> 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.
>>>
>>>
>> --
>> [ ]'s
>> Aledr - Alexandre
>> "OpenSource Solutions for SmallBusiness Problems"
>
> - --
> Snorby SSD: The IDS (Intrusion Detection System) Linux distribution
> http://bailey.st/blog/snorby-spsa/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQEcBAEBAgAGBQJNPK10AAoJENNBJKHbaDgTKN0IAL7YlR/rmtcrj9GDbTCUElu4
> 81t+0Y8let5XgnvYGVjbaUyPP+BwxhoWpN8f6PqFfohPbj+Xt9EuSdJIV9Wr84Bi
> NLhWtQyw/ioFZaDH1b50smEfR1qqIsQRd+wfbor21cwe5YhjorZ9FuPoH1HBFFPp
> 4kct+b0vMuGb0OjlWRosVAe/p3mzbNbn8glVhqaBthAl6GmAOrBuEmRqdB6jgN2s
> /fLNGKi08YdlbHn5hvnmXTONiFQf5aA40ZpKlTmCWHJUiVINfuUw7FE5E/ZuYve2
> l7Vs2BIIKy3X4oRFZbeQXV/yVyOKygIwdmzJZ+iBLL4zdST8YA3Zj/8Q73pX434=
> =6lwe
> -END PGP SIGNATURE-
>
> --
> 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 

Re: Django Improper Configuration

[Graham Dumpleton]

Provide  the full error including any Python traceback so we can see where 
the error is occurring. If running manage.py runserver, easiest thing to do 
is to provide the whole output from running the command.

Graham

On Monday, January 24, 2011 1:11:47 PM UTC+11, Kimberly wrote:
>
> Still doesn't work. But thank you for trying to help me. It keep giving me 
> the same ENGINE configuration that it is not set.
>
> On Sun, Jan 23, 2011 at 8:05 PM, Graham Dumpleton 
> wrote:
>
>>
>>
>> On Monday, January 24, 2011 12:42:57 PM UTC+11, Kimberly wrote:
>>>
>>> Sorry about that... here is what I have in the settings.py ( similiar to 
>>> what you showed, but mine is abit different in the NAME section):
>>>
>>> DATABASES = {
>>> 'default': {
>>> 'ENGINE': 'django.db.backends.sqlite3', # Add 
>>> 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
>>> 'NAME':  'home/username/directory/database'  # Or 
>>> path to database file if using sqlite3.
>>>
>>
>> You deleted the comma after the string and missing leading slash on path. 
>> Try:
>>
>> 'NAME':  '/home/username/directory/database',  # 
>> Or path to database file if using sqlite3.
>>
>> Not sure how you didn't just get a syntax error.
>>
>> Graham
>>  
>>
>>> 'USER': '',  # Not used with sqlite3.
>>> 'PASSWORD': '',  # Not used with sqlite3.
>>> 'HOST': '',  # Set to empty string for 
>>> localhost. Not used with sqlite3.
>>> 'PORT': '',  # Set to empty string for 
>>> default. Not used with sqlite3.
>>> }
>>> }
>>>
>>> Inside the settings.py file, in the template_dirs section, there's a line 
>>> says os.path.join(os.path.dirname(_file_), 'templates')
>>>
>>> If I comment that, then there's a error saying it doesn't recognize 
>>> _file_. I commented that line, then it says that the setting ENGINE has not 
>>> been set.
>>>
>>>
>>> On Sun, Jan 23, 2011 at 7:32 PM, Graham Dumpleton wrote:
>>>
  Rather than have us guess what is in your settings file, post that 
 whole section. For example:

 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.sqlite3', # Add 
 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
 'NAME': os.path.join(ENVIRON_ROOT, 'db', 'database.db'), 
  # Or path to database file if using sqlite3.
 'USER': '',  # Not used with sqlite3.
 'PASSWORD': '',  # Not used with sqlite3.
 'HOST': '',  # Set to empty string for 
 localhost. Not used with sqlite3.
 'PORT': '',  # Set to empty string for 
 default. Not used with sqlite3.
 }
 }

 This will allow everyone to see if you have mucked up some other part of 
 the settings.

 Graham

 On Monday, January 24, 2011 11:39:02 AM UTC+11, Kimberly wrote:

>  I've used the tutorials and it doesn't work. I've done exactly what 
> the tutorial says, and it keeps saying that the ENGINE has not been set 
> in 
> the setting. I am also using Django 1.2 or higher version.
>
> On Sun, Jan 23, 2011 at 6:29 PM, Karen Tracey wrote:
>
>>  On Sun, Jan 23, 2011 at 6:47 PM, Kimberly Harvey 
>> wrote:
>>
>>> it still doesn't work. I typed it like you've suggested and it keeps 
>>> saying that the database ENGINE has not been set.
>>>
>>>
>> If you are using ENGINE by itself, you need to be using Django 1.2 or 
>> higher and ENGINE is a key in the dictionary of settings for the default 
>> database, not a single ENGINE line in settings.py. See: 
>>
>>
>> http://docs.djangoproject.com/en/dev/ref/settings/?from=olddocs#databases
>>
>> for details. 
>>
>> If you are using a Django version prior to 1.2, the setting you should 
>> be using is DATABASE_ENGINE (see 
>> http://docs.djangoproject.com/en/1.1/ref/settings/#database-engine), 
>> not just ENGINE.
>>
>> Karen
>> -- 
>> http://tracey.org/kmt/
>>
>>  -- 
>> You received this message because you are subscribed to the Google 
>> Groups "Django users" group.
>> To post to this group, send email to dja...@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> djang...@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 djan...@googlegroups.com.
 To unsubscribe from this group, send email to 
 django-...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group

Re: Django Improper Configuration

[Kimberly Harvey]

Still doesn't work. But thank you for trying to help me. It keep giving me
the same ENGINE configuration that it is not set.

On Sun, Jan 23, 2011 at 8:05 PM, Graham Dumpleton <
graham.dumple...@gmail.com> wrote:

>
>
> On Monday, January 24, 2011 12:42:57 PM UTC+11, Kimberly wrote:
>>
>> Sorry about that... here is what I have in the settings.py ( similiar to
>> what you showed, but mine is abit different in the NAME section):
>>
>> DATABASES = {
>> 'default': {
>> 'ENGINE': 'django.db.backends.sqlite3', # Add
>> 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
>> 'NAME':  'home/username/directory/database'  # Or
>> path to database file if using sqlite3.
>>
>
> You deleted the comma after the string and missing leading slash on path.
> Try:
>
> 'NAME':  '/home/username/directory/database',  # Or
> path to database file if using sqlite3.
>
> Not sure how you didn't just get a syntax error.
>
> Graham
>
>
>> 'USER': '',  # Not used with sqlite3.
>> 'PASSWORD': '',  # Not used with sqlite3.
>> 'HOST': '',  # Set to empty string for
>> localhost. Not used with sqlite3.
>> 'PORT': '',  # Set to empty string for
>> default. Not used with sqlite3.
>> }
>> }
>>
>> Inside the settings.py file, in the template_dirs section, there's a line
>> says os.path.join(os.path.dirname(_file_), 'templates')
>>
>> If I comment that, then there's a error saying it doesn't recognize
>> _file_. I commented that line, then it says that the setting ENGINE has not
>> been set.
>>
>>
>> On Sun, Jan 23, 2011 at 7:32 PM, Graham Dumpleton 
>> wrote:
>>
>>> Rather than have us guess what is in your settings file, post that whole
>>> section. For example:
>>>
>>> DATABASES = {
>>> 'default': {
>>> 'ENGINE': 'django.db.backends.sqlite3', # Add
>>> 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
>>> 'NAME': os.path.join(ENVIRON_ROOT, 'db', 'database.db'),
>>>  # Or path to database file if using sqlite3.
>>> 'USER': '',  # Not used with sqlite3.
>>> 'PASSWORD': '',  # Not used with sqlite3.
>>> 'HOST': '',  # Set to empty string for
>>> localhost. Not used with sqlite3.
>>> 'PORT': '',  # Set to empty string for
>>> default. Not used with sqlite3.
>>> }
>>> }
>>>
>>> This will allow everyone to see if you have mucked up some other part of
>>> the settings.
>>>
>>> Graham
>>>
>>> On Monday, January 24, 2011 11:39:02 AM UTC+11, Kimberly wrote:
>>>
 I've used the tutorials and it doesn't work. I've done exactly what the
 tutorial says, and it keeps saying that the ENGINE has not been set in the
 setting. I am also using Django 1.2 or higher version.

 On Sun, Jan 23, 2011 at 6:29 PM, Karen Tracey  wrote:

>  On Sun, Jan 23, 2011 at 6:47 PM, Kimberly Harvey wrote:
>
>> it still doesn't work. I typed it like you've suggested and it keeps
>> saying that the database ENGINE has not been set.
>>
>>
> If you are using ENGINE by itself, you need to be using Django 1.2 or
> higher and ENGINE is a key in the dictionary of settings for the default
> database, not a single ENGINE line in settings.py. See:
>
>
> http://docs.djangoproject.com/en/dev/ref/settings/?from=olddocs#databases
>
> for details.
>
> If you are using a Django version prior to 1.2, the setting you should
> be using is DATABASE_ENGINE (see
> http://docs.djangoproject.com/en/1.1/ref/settings/#database-engine),
> not just ENGINE.
>
> Karen
> --
> http://tracey.org/kmt/
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To post to this group, send email to djan...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-...@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...@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 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 becau

Re: Django Improper Configuration

[Graham Dumpleton]

On Monday, January 24, 2011 12:42:57 PM UTC+11, Kimberly wrote:
>
> Sorry about that... here is what I have in the settings.py ( similiar to 
> what you showed, but mine is abit different in the NAME section):
>
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.sqlite3', # Add 
> 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
> 'NAME':  'home/username/directory/database'  # Or 
> path to database file if using sqlite3.
>

You deleted the comma after the string and missing leading slash on path. 
Try:

'NAME':  '/home/username/directory/database',  # Or 
path to database file if using sqlite3.

Not sure how you didn't just get a syntax error.

Graham
 

> 'USER': '',  # Not used with sqlite3.
> 'PASSWORD': '',  # Not used with sqlite3.
> 'HOST': '',  # Set to empty string for 
> localhost. Not used with sqlite3.
> 'PORT': '',  # Set to empty string for default. 
> Not used with sqlite3.
> }
> }
>
> Inside the settings.py file, in the template_dirs section, there's a line 
> says os.path.join(os.path.dirname(_file_), 'templates')
>
> If I comment that, then there's a error saying it doesn't recognize _file_. 
> I commented that line, then it says that the setting ENGINE has not been 
> set.
>
>
> On Sun, Jan 23, 2011 at 7:32 PM, Graham Dumpleton 
> wrote:
>
>> Rather than have us guess what is in your settings file, post that whole 
>> section. For example:
>>
>> DATABASES = {
>> 'default': {
>> 'ENGINE': 'django.db.backends.sqlite3', # Add 
>> 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
>> 'NAME': os.path.join(ENVIRON_ROOT, 'db', 'database.db'),   
>># Or path to database file if using sqlite3.
>> 'USER': '',  # Not used with sqlite3.
>> 'PASSWORD': '',  # Not used with sqlite3.
>> 'HOST': '',  # Set to empty string for 
>> localhost. Not used with sqlite3.
>> 'PORT': '',  # Set to empty string for 
>> default. Not used with sqlite3.
>> }
>> }
>>
>> This will allow everyone to see if you have mucked up some other part of 
>> the settings.
>>
>> Graham
>>
>> On Monday, January 24, 2011 11:39:02 AM UTC+11, Kimberly wrote:
>>
>>> I've used the tutorials and it doesn't work. I've done exactly what the 
>>> tutorial says, and it keeps saying that the ENGINE has not been set in the 
>>> setting. I am also using Django 1.2 or higher version.
>>>
>>> On Sun, Jan 23, 2011 at 6:29 PM, Karen Tracey  wrote:
>>>
  On Sun, Jan 23, 2011 at 6:47 PM, Kimberly Harvey wrote:

> it still doesn't work. I typed it like you've suggested and it keeps 
> saying that the database ENGINE has not been set.
>
>
 If you are using ENGINE by itself, you need to be using Django 1.2 or 
 higher and ENGINE is a key in the dictionary of settings for the default 
 database, not a single ENGINE line in settings.py. See: 


 http://docs.djangoproject.com/en/dev/ref/settings/?from=olddocs#databases

 for details. 

 If you are using a Django version prior to 1.2, the setting you should 
 be using is DATABASE_ENGINE (see 
 http://docs.djangoproject.com/en/1.1/ref/settings/#database-engine), 
 not just ENGINE.

 Karen
 -- 
 http://tracey.org/kmt/

  -- 
 You received this message because you are subscribed to the Google 
 Groups "Django users" group.
 To post to this group, send email to djan...@googlegroups.com.
 To unsubscribe from this group, send email to 
 django-...@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...@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 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: Questions - Django -- Bash problem

[Kimberly Harvey]

By the way, it is Django 1.2.4 to be exact

On Sun, Jan 23, 2011 at 7:38 PM, Karen Tracey  wrote:

> On Sun, Jan 23, 2011 at 8:27 PM, Kimberly Harvey wrote:
>
>> Problems ( this is very frustrating!).
>>
>> In the settings.py file, I'm using the django 1.2 or higher, so it has
>> ENGINE : '", and whatsnot
>> I set the ENGINE to sqlite3, that didn't work. Then I added the path, and
>> that still doesn't work. It keeps saying that the ENGINE has not been set. I
>> have no clue what is wrong, I've gone through the tutorial so many times and
>> I feel that there must be something I am overlooking. I am using the Django
>> in the Linux-Debian. Please help, because Django is not cooperating with the
>> database and I have no clue what is going on other than the engine part but
>> that has been set.
>>
>>
> It might help if you copy/pasted the database settings portion from your
> settings.py file into your email to the group. You say you have taken it
> exactly from the tutorial but the error message is saying something else,
> and in such cases the error message is generally correct: really, the
> tutorial is not entirely broken so you have something that is not right but
> you have not given us enough information to help diagnose what it is. (That
> too is frustrating.)
>
> Also please indicate exactly what level of Django you are using. Why do you
> say 1.2 or higher?  That's what I said to indicate what level you need in
> order to use the settings syntax you appear to be using but you ought to
> know exactly what you are using, and be able to state that. The fact that
> you are saying 1.2 or higher instead of stating exactly what you are using
> does not give me confidence that you know what level you are using. One of
> the reasons you would be getting the error message you are reporting is if
> you are in fact using 1.1 but trying to use 1.2 syntax for the database
> settings.
>
> Karen
> --
> http://tracey.org/kmt/
>
>  --
> 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: Questions - Django -- Bash problem

[Kimberly Harvey]

Karen, I've already posted the result to the board. I am new to this Django
world so I do not have full confident with how all of this work. Just
started learning, so this is very new to me.

By the way, sorry that I did not post the result earlier along with my
frustration, I wasn't thinking, so I apologize once again. I am using Django
1.2 and to ensure that the Django has been installed, I run a test in the
shell and it exists.

On Sun, Jan 23, 2011 at 7:38 PM, Karen Tracey  wrote:

> On Sun, Jan 23, 2011 at 8:27 PM, Kimberly Harvey wrote:
>
>> Problems ( this is very frustrating!).
>>
>> In the settings.py file, I'm using the django 1.2 or higher, so it has
>> ENGINE : '", and whatsnot
>> I set the ENGINE to sqlite3, that didn't work. Then I added the path, and
>> that still doesn't work. It keeps saying that the ENGINE has not been set. I
>> have no clue what is wrong, I've gone through the tutorial so many times and
>> I feel that there must be something I am overlooking. I am using the Django
>> in the Linux-Debian. Please help, because Django is not cooperating with the
>> database and I have no clue what is going on other than the engine part but
>> that has been set.
>>
>>
> It might help if you copy/pasted the database settings portion from your
> settings.py file into your email to the group. You say you have taken it
> exactly from the tutorial but the error message is saying something else,
> and in such cases the error message is generally correct: really, the
> tutorial is not entirely broken so you have something that is not right but
> you have not given us enough information to help diagnose what it is. (That
> too is frustrating.)
>
> Also please indicate exactly what level of Django you are using. Why do you
> say 1.2 or higher?  That's what I said to indicate what level you need in
> order to use the settings syntax you appear to be using but you ought to
> know exactly what you are using, and be able to state that. The fact that
> you are saying 1.2 or higher instead of stating exactly what you are using
> does not give me confidence that you know what level you are using. One of
> the reasons you would be getting the error message you are reporting is if
> you are in fact using 1.1 but trying to use 1.2 syntax for the database
> settings.
>
> Karen
> --
> http://tracey.org/kmt/
>
>  --
> 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: Django Improper Configuration

[Kimberly Harvey]

Sorry about that... here is what I have in the settings.py ( similiar to
what you showed, but mine is abit different in the NAME section):

DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3', # Add 'postgresql_psycopg2',
'postgresql', 'mysql', 'sqlite3' or 'oracle'.
'NAME':  'home/username/directory/database'  # Or
path to database file if using sqlite3.
'USER': '',  # Not used with sqlite3.
'PASSWORD': '',  # Not used with sqlite3.
'HOST': '',  # Set to empty string for
localhost. Not used with sqlite3.
'PORT': '',  # Set to empty string for default.
Not used with sqlite3.
}
}

Inside the settings.py file, in the template_dirs section, there's a line
says os.path.join(os.path.dirname(_file_), 'templates')

If I comment that, then there's a error saying it doesn't recognize _file_.
I commented that line, then it says that the setting ENGINE has not been
set.


On Sun, Jan 23, 2011 at 7:32 PM, Graham Dumpleton <
graham.dumple...@gmail.com> wrote:

> Rather than have us guess what is in your settings file, post that whole
> section. For example:
>
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.db.backends.sqlite3', # Add
> 'postgresql_psycopg2', 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
> 'NAME': os.path.join(ENVIRON_ROOT, 'db', 'database.db'),
># Or path to database file if using sqlite3.
> 'USER': '',  # Not used with sqlite3.
> 'PASSWORD': '',  # Not used with sqlite3.
> 'HOST': '',  # Set to empty string for
> localhost. Not used with sqlite3.
> 'PORT': '',  # Set to empty string for default.
> Not used with sqlite3.
> }
> }
>
> This will allow everyone to see if you have mucked up some other part of
> the settings.
>
> Graham
>
> On Monday, January 24, 2011 11:39:02 AM UTC+11, Kimberly wrote:
>
>> I've used the tutorials and it doesn't work. I've done exactly what the
>> tutorial says, and it keeps saying that the ENGINE has not been set in the
>> setting. I am also using Django 1.2 or higher version.
>>
>> On Sun, Jan 23, 2011 at 6:29 PM, Karen Tracey  wrote:
>>
>>> On Sun, Jan 23, 2011 at 6:47 PM, Kimberly Harvey wrote:
>>>
 it still doesn't work. I typed it like you've suggested and it keeps
 saying that the database ENGINE has not been set.


>>> If you are using ENGINE by itself, you need to be using Django 1.2 or
>>> higher and ENGINE is a key in the dictionary of settings for the default
>>> database, not a single ENGINE line in settings.py. See:
>>>
>>> http://docs.djangoproject.com/en/dev/ref/settings/?from=olddocs#databases
>>>
>>> for details.
>>>
>>> If you are using a Django version prior to 1.2, the setting you should be
>>> using is DATABASE_ENGINE (see
>>> http://docs.djangoproject.com/en/1.1/ref/settings/#database-engine), not
>>> just ENGINE.
>>>
>>> Karen
>>> --
>>> http://tracey.org/kmt/
>>>
>>>  --
>>> You received this message because you are subscribed to the Google Groups
>>> "Django users" group.
>>> 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 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: Questions - Django -- Bash problem

[Karen Tracey]

On Sun, Jan 23, 2011 at 8:27 PM, Kimberly Harvey wrote:

> Problems ( this is very frustrating!).
>
> In the settings.py file, I'm using the django 1.2 or higher, so it has
> ENGINE : '", and whatsnot
> I set the ENGINE to sqlite3, that didn't work. Then I added the path, and
> that still doesn't work. It keeps saying that the ENGINE has not been set. I
> have no clue what is wrong, I've gone through the tutorial so many times and
> I feel that there must be something I am overlooking. I am using the Django
> in the Linux-Debian. Please help, because Django is not cooperating with the
> database and I have no clue what is going on other than the engine part but
> that has been set.
>
>
It might help if you copy/pasted the database settings portion from your
settings.py file into your email to the group. You say you have taken it
exactly from the tutorial but the error message is saying something else,
and in such cases the error message is generally correct: really, the
tutorial is not entirely broken so you have something that is not right but
you have not given us enough information to help diagnose what it is. (That
too is frustrating.)

Also please indicate exactly what level of Django you are using. Why do you
say 1.2 or higher?  That's what I said to indicate what level you need in
order to use the settings syntax you appear to be using but you ought to
know exactly what you are using, and be able to state that. The fact that
you are saying 1.2 or higher instead of stating exactly what you are using
does not give me confidence that you know what level you are using. One of
the reasons you would be getting the error message you are reporting is if
you are in fact using 1.1 but trying to use 1.2 syntax for the database
settings.

Karen
-- 
http://tracey.org/kmt/

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

[Graham Dumpleton]

Rather than have us guess what is in your settings file, post that whole 
section. For example:

DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3', # Add 'postgresql_psycopg2', 
'postgresql', 'mysql', 'sqlite3' or 'oracle'.
'NAME': os.path.join(ENVIRON_ROOT, 'db', 'database.db'), 
 # Or path to database file if using sqlite3.
'USER': '',  # Not used with sqlite3.
'PASSWORD': '',  # Not used with sqlite3.
'HOST': '',  # Set to empty string for 
localhost. Not used with sqlite3.
'PORT': '',  # Set to empty string for default. 
Not used with sqlite3.
}
}

This will allow everyone to see if you have mucked up some other part of the 
settings.

Graham

On Monday, January 24, 2011 11:39:02 AM UTC+11, Kimberly wrote:
>
> I've used the tutorials and it doesn't work. I've done exactly what the 
> tutorial says, and it keeps saying that the ENGINE has not been set in the 
> setting. I am also using Django 1.2 or higher version.
>
> On Sun, Jan 23, 2011 at 6:29 PM, Karen Tracey  wrote:
>
>> On Sun, Jan 23, 2011 at 6:47 PM, Kimberly Harvey wrote:
>>
>>> it still doesn't work. I typed it like you've suggested and it keeps 
>>> saying that the database ENGINE has not been set.
>>>
>>>
>> If you are using ENGINE by itself, you need to be using Django 1.2 or 
>> higher and ENGINE is a key in the dictionary of settings for the default 
>> database, not a single ENGINE line in settings.py. See: 
>>
>> http://docs.djangoproject.com/en/dev/ref/settings/?from=olddocs#databases
>>
>> for details. 
>>
>> If you are using a Django version prior to 1.2, the setting you should be 
>> using is DATABASE_ENGINE (see 
>> http://docs.djangoproject.com/en/1.1/ref/settings/#database-engine), not 
>> just ENGINE.
>>
>> Karen
>> -- 
>> http://tracey.org/kmt/
>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> 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 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: Questions - Django -- Bash problem

[Kimberly Harvey]

Problems ( this is very frustrating!).

In the settings.py file, I'm using the django 1.2 or higher, so it has
ENGINE : '", and whatsnot
I set the ENGINE to sqlite3, that didn't work. Then I added the path, and
that still doesn't work. It keeps saying that the ENGINE has not been set. I
have no clue what is wrong, I've gone through the tutorial so many times and
I feel that there must be something I am overlooking. I am using the Django
in the Linux-Debian. Please help, because Django is not cooperating with the
database and I have no clue what is going on other than the engine part but
that has been set.

2011/1/23 Łukasz Rekucki 

> On 23 January 2011 11:54, Kimberly  wrote:
> > Hello, I have another question. When it comes to Django, I notice some
> > people type as django-admin startproject project and some have to type
> > as django-admin.py startproject project ( in my case, I had to do
> > that), is it base on the setup of the Django that cause the
> > differences between the admin.py and admin?
>
> Django provides the script as "django-admin.py"; Some Linux
> distributions (like Ubuntu) package Django with the script renamed to
> "django-admin". So that's the cause of the difference and it's not
> something that Django has any influence on.
>
> >
> > Also, on the command line, I typed " manage.py startapp tolls"  after
> > being side my project directory and now it says bash: manage.py:
> > command not found
>
> Yes, because that's how bash works. If the script is not on PATH, then
> bash won't find it. If you want to run a script from current
> directory:
>
>./manage.py startapp tolls
>
> Note, that the file has to be executable, for this to work (it's not
> by default). That's why Django's tutorial suggests writing:
>
>python manage.py startapp tolls
>
> To avoid the need of explaining about bash, permission, etc.
>
> >
> > I've checked the directory I am using and the manage.py file is there.
> > I also set the _init_.py to where the operating system - os is
> > imported and that the django_setting_module is set to settings. Any
> > advices will be greatly appreciated. Thanks!
> >
>
> --
> Łukasz Rekucki
>
> --
> 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: Django Improper Configuration

[Kimberly Harvey]

I've used the tutorials and it doesn't work. I've done exactly what the
tutorial says, and it keeps saying that the ENGINE has not been set in the
setting. I am also using Django 1.2 or higher version.

On Sun, Jan 23, 2011 at 6:29 PM, Karen Tracey  wrote:

> On Sun, Jan 23, 2011 at 6:47 PM, Kimberly Harvey wrote:
>
>> it still doesn't work. I typed it like you've suggested and it keeps
>> saying that the database ENGINE has not been set.
>>
>>
> If you are using ENGINE by itself, you need to be using Django 1.2 or
> higher and ENGINE is a key in the dictionary of settings for the default
> database, not a single ENGINE line in settings.py. See:
>
> http://docs.djangoproject.com/en/dev/ref/settings/?from=olddocs#databases
>
> for details.
>
> If you are using a Django version prior to 1.2, the setting you should be
> using is DATABASE_ENGINE (see
> http://docs.djangoproject.com/en/1.1/ref/settings/#database-engine), not
> just ENGINE.
>
> Karen
> --
> http://tracey.org/kmt/
>
>  --
> 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: Django Improper Configuration

[Karen Tracey]

On Sun, Jan 23, 2011 at 6:47 PM, Kimberly Harvey wrote:

> it still doesn't work. I typed it like you've suggested and it keeps saying
> that the database ENGINE has not been set.
>
>
If you are using ENGINE by itself, you need to be using Django 1.2 or higher
and ENGINE is a key in the dictionary of settings for the default database,
not a single ENGINE line in settings.py. See:

http://docs.djangoproject.com/en/dev/ref/settings/?from=olddocs#databases

for details.

If you are using a Django version prior to 1.2, the setting you should be
using is DATABASE_ENGINE (see
http://docs.djangoproject.com/en/1.1/ref/settings/#database-engine), not
just ENGINE.

Karen
-- 
http://tracey.org/kmt/

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

[Kimberly Harvey]

it still doesn't work. I typed it like you've suggested and it keeps saying
that the database ENGINE has not been set.

On Sun, Jan 23, 2011 at 5:11 AM, Mark Penix  wrote:

> your whole engine line should read
> 'ENGINE': 'django.db.backends.sqlite3'
>
> --
> 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: local variable 'qft' referenced before assignment

[bruno desthuilliers]

On 23 jan, 23:20, Trevor Stanley  wrote:
> Thanks Bruno for the critique and you are right I don't know what I'm
> doing and I am rather learning by accident.  I am not a programmer and
> don't profess to be one(yet).  I have built the apps in the excellent
> book, Practical Django Projects and I have also worked through, The
> Definitive Guide to Django which I have by my side.  I also have Pro
> Django on stand-by.  I know it may take me some time to get where I need
> to be in order to successfully write fluent Django code

(snip)

> If you have any tips as to where you think I may be able to obtain some
> good tuition I would be pleased to hear about it.

Well, the first point is that you're not writing "django" code but
Python. Django is a framework, but the language is Python, and you
have to learn the language itself to be able to properly use the
framework. I strongly suggest you spend some times doing the official
Python tutorial before anything else. The Python usenet group (that
you can join thru google groups) is a very newbie friendly place (at
least by usenet standards) so don't be afraid to post python related
questions there.

wrt/ programming by accident, I guess we all (well, most of us) start
this way, then realize it's not the best thing to do. One of the nice
points with Python is the interactive shell that let you experiment
with the language and most libs / frameworks / whatever, so you don't
have to write hundreds lines of code just to find out you got it all
wrong - just read the doc (first, mandatory step), then fire the
interpreter and try out "live".

Once you get a better grasp of the language itself, you have to have
at least a basic understanding of what the Django framework try to
"abstract" : relational databases (IOW: SQL) and the HTTP protocol. If
you don't understand what Django is doing for you, you'll never be
able to use it properly.

My 2 cents...

-- 
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: Confused by __unicode_cast and __str_cast in django.utils.functional

[Lachlan Musicman]

On Sun, Jan 23, 2011 at 20:40, Kevin Xiao  wrote:
> Hi,
>
> I am stuck while look into source code of Django's lazy decorator. At
> line 205 of functinal.py, there is:
>
>  def __unicode_cast(self):
>            return self.__func(*self.__args, **self.__kw)
>
>  def __str_cast(self):
>            return str(self.__func(*self.__args, **self.__kw))
>
> Why doesn't __unicode_cast function need to call *unicode* on
> *self.__func(...)* like what __str_cast does,call *str* function?
>
> Any help is appreciated.

Kevin,

Almost 100% certain that this question will be answered quicker on the
django-dev list:

email: django-develop...@googlegroups.com

web: http://groups.google.com/group/django-developers?hl=en


cheers
L.




-- 
Crunchiness is the gustatory sensation of muffled grinding of a
foodstuff. Crunchiness differs from crispiness in that a crispy item
is quickly atomized, while a crunchy one offers sustained, granular
resistance to jaw action. While crispiness is difficult to maintain,
crunchiness is difficult to overcome.
from The Best of Wikipedia http://bestofwikipedia.tumblr.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: Having some problems with admin css and such

[Wes Wagner]

Figured it out...

STATICFILES_DIRS = ( STATIC_ROOT,)

Had to add my static root directory to the static files dir...

Am I doing something kludgy or is the current documentation revision
in the SVN wrong?

-Wes


On Jan 23, 10:32 am, Wes Wagner  wrote:
> I just started building a new app in 1.3 and I am having some static
> files problems (I read the new documentation)
>
> I am using pycharm as an IDE.
>
> If I run a collectstatic it will actually dump all the admin static
> files into my /static directory under my project but I can't get it so
> serve any of them under runserver. (not found)
>
> Thus admin runs without any css or graphics
>
> Settings:
> MEDIA_ROOT = ''
> MEDIA_URL = ''
> STATIC_ROOT = "C:/Users/Wes Wagner/PycharmProjects/APP/static/"
> STATIC_URL = '/static/'
> ADMIN_MEDIA_PREFIX = '/static/admin/'
>
> in URLS I added:
> from django.contrib.staticfiles.urls import staticfiles_urlpatterns
> and to the end of my file:
> urlpatterns += staticfiles_urlpatterns()
>
> If I just hit the base directory my urls list looks like this:
> Using the URLconf defined in APP.urls, Django tried these URL
> patterns, in this order:
>     ^admin/
>     ^static\/
>
> The backslash prior to the / creeps me out a little... this is a
> windows 7 x64, python 2.6 using the tarball of 1.3 from today.
>
> So what noobish mistake did I make this time? 8)
>
> -Wes Wagner

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

Adding to admin logic

[Tom]

Hello,

I am trying to get the company that I work at to use Django and Python
for future webdevelopment (whereas now that is done with PHP). We have
lots of different customers with lots of different website needs so
the datamodel is different so webframeworks are good choice (over CMS
maybe) and Django rocks so use that, is the reasoning :P.

To make a use case and test the framework out I'm making an app called
treepages that with models Page (tree) and Field I can make a
structure of webpages with editable fields in the backend. I could use
the admin to add and remove fields and maybe even disable that
functionality in production for that site so they can only change page
content, not structure.

The way I'd like it to work is to change the index view of the page
model of the treepages app in the admin to my custom view function.
The problem here for me is that even if I make a route to my own app
controller instead of the admin one I don't know if and how I can get
my own view function to behave like an django admin view but then
include my own logic i.e. how do I integrate with the admin 'session'.

Later I might be interested in changing other views in the admin as
well to for example have a custom 'dashboard' on the index view when
enabled in the 'misc settings' view etc.

I understand that this might have been asked before but even if the
admin wasn't really made for this (though it's all strictly adminny
stuff meant for the client administrators and not the frontend users
of the site..) is it possible?

Greetings,

Tom Wieland

-- 
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: 32-bit integers IP address to 4-octet IP address

[phil...@bailey.st]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I aledr,

thanks for your reply,


I've added the  socket.inet_ntoa to my  view.py

#view.py
from django.http import HttpResponse
import socket
from snort.models import  Iphdr


def snort(request):

ip = Iphdr.objects.values("ip_src")
return socket.inet_ntoa(ip)


after opening the web page I get this error bac





Request Method: GET
Request URL:http://192.168.1.5:8080/
Django Version: 1.3 beta 1
Exception Type: TypeError
Exception Value:

inet_aton() argument 1 must be string, not ValuesQuerySet

Exception Location: /home/user/django/app/../snort/views.py in snort,
line 10
Python Executable:  /usr/bin/python
Python Version: 2.6.5
Python Path:

['/home/crypto/django/snort',
 '/usr/lib/python2.6',
 '/usr/lib/python2.6/plat-linux2',
 '/usr/lib/python2.6/lib-tk',
 '/usr/lib/python2.6/lib-old',
 '/usr/lib/python2.6/lib-dynload',
 '/usr/lib/python2.6/dist-packages',
 '/usr/lib/pymodules/python2.6',
 '/usr/lib/pymodules/python2.6/gtk-2.0',
 '/usr/lib/python2.6/dist-packages/wx-2.8-gtk2-unicode',
 '/usr/local/lib/python2.6/dist-packages']
~


What I'm doing wrong ?

Thanks again,

Phillip



On 01/23/2011 07:18 PM, aledr wrote:
> I guess socket.inet_ntoa is enough for what you need.
> 
> On Sun, Jan 23, 2011 at 7:06 AM, Phillip Bailey  wrote:
> 
> 
> Dear All,
> 
> I've started playing around with Django in the last few days, and I'm
> enjoying the speed
> and the power of such framework. I'm writing a small application to
> display and sort
> ip addresses stored in a Postgresql database, right now I'm stuck with
> 32-bit integers
> IP address translated to 4-octet IP address .
> 
> Here's the the class of the ip address.
> 
> class Iphdr(models.Model):
>sid = models.IntegerField(primary_key=True)
>cid = models.BigIntegerField(primary_key=True)
>ip_src = models.BigIntegerField()
>ip_dst = models.BigIntegerField()
>ip_ver = models.SmallIntegerField()
>ip_hlen = models.SmallIntegerField()
>ip_tos = models.SmallIntegerField()
>ip_len = models.IntegerField()
>ip_id = models.IntegerField()
>ip_flags = models.SmallIntegerField()
>ip_off = models.IntegerField()
>ip_ttl = models.SmallIntegerField()
>ip_proto = models.SmallIntegerField()
>ip_csum = models.IntegerField()
>class Meta:
>db_table = u'iphdr'
> 
> 
> As the IP addresses are stored in the database as unsigned 32-bit
> integers, so when I
> run  ip = Iphdr.objects.values("ip_src") the result is in 32-bit integers,
> 
> {'ip_src': 3251031814L}{'ip_src': 3251031816L}{'ip_src': 3251031816L}
> {'ip_src': 3251031816L}{'ip_src': 3251031814L}{'ip_src': 3251031816L}
> 
> There's any elegant solution that can translate 32-bit integers to
> 4-octet IP address (192.168.1.88) ?
> 
> Thanks in advance.
> 
> Phillip
>>
- --
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.
>>
>>
> --
> [ ]'s
> Aledr - Alexandre
> "OpenSource Solutions for SmallBusiness Problems"

- -- 
Snorby SSD: The IDS (Intrusion Detection System) Linux distribution
http://bailey.st/blog/snorby-spsa/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJNPK10AAoJENNBJKHbaDgTKN0IAL7YlR/rmtcrj9GDbTCUElu4
81t+0Y8let5XgnvYGVjbaUyPP+BwxhoWpN8f6PqFfohPbj+Xt9EuSdJIV9Wr84Bi
NLhWtQyw/ioFZaDH1b50smEfR1qqIsQRd+wfbor21cwe5YhjorZ9FuPoH1HBFFPp
4kct+b0vMuGb0OjlWRosVAe/p3mzbNbn8glVhqaBthAl6GmAOrBuEmRqdB6jgN2s
/fLNGKi08YdlbHn5hvnmXTONiFQf5aA40ZpKlTmCWHJUiVINfuUw7FE5E/ZuYve2
l7Vs2BIIKy3X4oRFZbeQXV/yVyOKygIwdmzJZ+iBLL4zdST8YA3Zj/8Q73pX434=
=6lwe
-END PGP SIGNATURE-

-- 
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: local variable 'qft' referenced before assignment

[Trevor Stanley]

Thanks Bruno for the critique and you are right I don't know what I'm 
doing and I am rather learning by accident.  I am not a programmer and 
don't profess to be one(yet).  I have built the apps in the excellent 
book, Practical Django Projects and I have also worked through, The 
Definitive Guide to Django which I have by my side.  I also have Pro 
Django on stand-by.  I know it may take me some time to get where I need 
to be in order to successfully write fluent Django code but I do intend 
to keep banging away at it.


Many thanks for you resolution to my problem I now have that part of the 
app working and can move on to the next bit.  I think I was plainly 
over-thinking the issue and had made things far more complicated than 
they needed to be.


If you have any tips as to where you think I may be able to obtain some 
good tuition I would be pleased to hear about it.


Trevor

bruno desthuilliers wrote:

On 23 jan, 17:27, Trevor Stanley  wrote:
  

   Karen

Thanks for your reply.  The reason I was trying to filter the id with
count was that I had read somewhere that you have to pass sum at least
two arguments (but may be I mis-understood what I was reading!)



The Python builtin sum() function takes an iterable and an optional
initial value (which defaults to int '0').
  

I have changed my code to:

def get_fringe_value(self):
ft =
Fringe.objects.select_related().filter(id__in=self.fringe.all()).values()



This is a very complicated and innefficient way to write:

  ft = self.fringe.select_related().values()

Also and FWIW, I don't see the need for a select_related here, so you
could as well make it:

  ft = self.fringe.values()

But since you only want to sum the percentages, what you want is
really:

  ft = self.fringe.values_list('percentage', flat=True)

and then apply sum() to this list.

But why use the builtin sum() when the database already knows how to
do a sum ?

  

qft=ft(sum('percentage'))



Err... you're trying to sum the chars in the 'percentage' string with
an initial value of int zero - ie, "sum('percentage')" is another way
to spell:

initial = 0
for char in "percentage":
   initial += char


Which obviously leads to the TypeError since you cannot add integers
and strings.

Also, I just don't get what result you'd expect from passing the
result of the call to 'some' to a call to ft.

To make a long story short: you don't know what you're doing and try
just anything that comes to your mind. This is called "programming by
accident", and is the best way to never learn to program.


  


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

Having some problems with admin css and such

[Wes Wagner]

I just started building a new app in 1.3 and I am having some static
files problems (I read the new documentation)

I am using pycharm as an IDE.

If I run a collectstatic it will actually dump all the admin static
files into my /static directory under my project but I can't get it so
serve any of them under runserver. (not found)

Thus admin runs without any css or graphics

Settings:
MEDIA_ROOT = ''
MEDIA_URL = ''
STATIC_ROOT = "C:/Users/Wes Wagner/PycharmProjects/APP/static/"
STATIC_URL = '/static/'
ADMIN_MEDIA_PREFIX = '/static/admin/'

in URLS I added:
from django.contrib.staticfiles.urls import staticfiles_urlpatterns
and to the end of my file:
urlpatterns += staticfiles_urlpatterns()


If I just hit the base directory my urls list looks like this:
Using the URLconf defined in APP.urls, Django tried these URL
patterns, in this order:
^admin/
^static\/

The backslash prior to the / creeps me out a little... this is a
windows 7 x64, python 2.6 using the tarball of 1.3 from today.

So what noobish mistake did I make this time? 8)

-Wes Wagner

-- 
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: 32-bit integers IP address to 4-octet IP address

[aledr]

I guess socket.inet_ntoa is enough for what you need.

On Sun, Jan 23, 2011 at 7:06 AM, Phillip Bailey  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> Dear All,
>
> I've started playing around with Django in the last few days, and I'm
> enjoying the speed
> and the power of such framework. I'm writing a small application to
> display and sort
> ip addresses stored in a Postgresql database, right now I'm stuck with
> 32-bit integers
> IP address translated to 4-octet IP address .
>
> Here's the the class of the ip address.
>
> class Iphdr(models.Model):
>    sid = models.IntegerField(primary_key=True)
>    cid = models.BigIntegerField(primary_key=True)
>    ip_src = models.BigIntegerField()
>    ip_dst = models.BigIntegerField()
>    ip_ver = models.SmallIntegerField()
>    ip_hlen = models.SmallIntegerField()
>    ip_tos = models.SmallIntegerField()
>    ip_len = models.IntegerField()
>    ip_id = models.IntegerField()
>    ip_flags = models.SmallIntegerField()
>    ip_off = models.IntegerField()
>    ip_ttl = models.SmallIntegerField()
>    ip_proto = models.SmallIntegerField()
>    ip_csum = models.IntegerField()
>    class Meta:
>        db_table = u'iphdr'
>
>
> As the IP addresses are stored in the database as unsigned 32-bit
> integers, so when I
> run  ip = Iphdr.objects.values("ip_src") the result is in 32-bit integers,
>
> {'ip_src': 3251031814L}{'ip_src': 3251031816L}{'ip_src': 3251031816L}
> {'ip_src': 3251031816L}{'ip_src': 3251031814L}{'ip_src': 3251031816L}
>
> There's any elegant solution that can translate 32-bit integers to
> 4-octet IP address (192.168.1.88) ?
>
> Thanks in advance.
>
> Phillip
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQEcBAEBAgAGBQJNO++eAAoJENNBJKHbaDgTM0cH/0/QjdPTi53tJG4YhjVpt6oj
> cJk6rAEHwFha//Vby4lH2sT+ZyKmv+UAjSVmvBCptXBOcm5LuedMmMCVeInfuliQ
> GeOPlQ4nvrZSbcdXirLu9Jqa+Yqj6nalGF7i0WetqvdsdrkQQdrcx1D814DSZKGq
> qQWpdyVEmdrRSfiOUvrYbnXDCnTwCXZdUhcpDNmD+5h9S2/uiMzP5cM2wtfMg1hO
> swYS9B7h/6vAd1ekOZh+ij2X4mszUfp5rQzFjCXtYnQma8pN+58UMpWwYVKj2FzA
> tgRaWC1Qz4hWsXRvwirqo/ZtyJMWxkOdwVaxl3iug/NCGW/yDCMa97zweYOHKCs=
> =W+IC
> -END PGP SIGNATURE-
>
> --
> 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.
>
>
--
[ ]'s
Aledr - Alexandre
"OpenSource Solutions for SmallBusiness Problems"

-- 
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: local variable 'qft' referenced before assignment

[bruno desthuilliers]

On 23 jan, 17:27, Trevor Stanley  wrote:
>    Karen
>
> Thanks for your reply.  The reason I was trying to filter the id with
> count was that I had read somewhere that you have to pass sum at least
> two arguments (but may be I mis-understood what I was reading!)

The Python builtin sum() function takes an iterable and an optional
initial value (which defaults to int '0').
> I have changed my code to:
>
>     def get_fringe_value(self):
>         ft =
>Fringe.objects.select_related().filter(id__in=self.fringe.all()).values()

This is a very complicated and innefficient way to write:

  ft = self.fringe.select_related().values()

Also and FWIW, I don't see the need for a select_related here, so you
could as well make it:

  ft = self.fringe.values()

But since you only want to sum the percentages, what you want is
really:

  ft = self.fringe.values_list('percentage', flat=True)

and then apply sum() to this list.

But why use the builtin sum() when the database already knows how to
do a sum ?

>         qft=ft(sum('percentage'))

Err... you're trying to sum the chars in the 'percentage' string with
an initial value of int zero - ie, "sum('percentage')" is another way
to spell:

initial = 0
for char in "percentage":
   initial += char


Which obviously leads to the TypeError since you cannot add integers
and strings.

Also, I just don't get what result you'd expect from passing the
result of the call to 'some' to a call to ft.

To make a long story short: you don't know what you're doing and try
just anything that comes to your mind. This is called "programming by
accident", and is the best way to never learn to program.


-- 
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: local variable 'qft' referenced before assignment

[Trevor Stanley]

  Karen

Thanks for your reply.  The reason I was trying to filter the id with 
count was that I had read somewhere that you have to pass sum at least 
two arguments (but may be I mis-understood what I was reading!)


I have changed my code to:

   def get_fringe_value(self):
   ft = 
Fringe.objects.select_related().filter(id__in=self.fringe.all()).values()

   qft=ft(sum('percentage'))
   return u'%d'%qft
  
   fringe_value = get_fringe_value



   def save(self):
   self.native_total = self.quantity*self.multiplier*self.value
   self.currency_total = 
self.quantity*self.multiplier*self.value*self.currency_code.rate1

   self.variance = self.currency_total-self.prev_total
   self.fringe_total = self.fringe_value()
   super(Detail, self).save()

Now I get the error:

File "/usr/lib/python2.5/site-packages/django/contrib/admin/options.py" 
in save_model

 597. obj.save()
File "/home/trevor/1stdjangoproject/mysite/../mysite/bt4/models.py" in save
 147. self.fringe_total = self.fringe_value()
File "/home/trevor/1stdjangoproject/mysite/../mysite/bt4/models.py" in 
get_fringe_value

 137. qft=ft(sum('percentage'))

Exception Type: TypeError at /admin/bt4/detail/1/
Exception Value: unsupported operand type(s) for +: 'int' and 'str'

I presume this is because I'm trying to convert a string to decimal when 
it doesn't have an integer type content(again I could be completely wrong)


How can I extract the Decimal value that is associated with the field 
'percentage'?


Here's the line from the admin debug screen which shows the values that 
ft is picking up - I would just like to sum zero, 1 or more of the 
'percentage' values when they are tagged(associated) to the current record.


ft
[{'ceiling': None, 'code': u'NI', 'description': u'UK National 
Insurance', 'floor': None, 'flat_rate': None, 'percentage': 
Decimal("0.128"), 'total': None, 'id': 1}, {'ceiling': None, 'code': 
u'HP', 'description': u'Holiday Pay', 'floor': None, 'flat_rate': None, 
'percentage': Decimal("0.1207"), 'total': None, 'id': 2}]



I apologise for these naive questions but I have to resolve this so I 
can understand how to build my app and continue with other functionality 
which will have a similar purpose.


Many thanks - Trevor

Karen Tracey wrote:
On Sat, Jan 22, 2011 at 9:43 AM, TAS > wrote:


 def get_fringe_value(self):
   ft =
Fringe.objects.select_related().filter(id__in=self.fringe.all()).values()
   if ft.count()==0:
   return u'%d'(0)
   if ft.count()==1:
   qft=ft.get('percentage')
   return u'%d'(qft)


You only set qft to something if ft.count() is 1. Yet the next line of 
code (the return, which uses the value of qft) is not indented to the 
same level as the assignment of qft, so it is not part of the 
ft.count() == 1conditional: it is going to be executed regardless of 
the ft.count() value. In the case where ft.count() is anything other 
than 1, that line of code is attempting to use the value of a variable 
that has not yet been set to anything. It can't complete successfully 
because the compiler doesn't know what to return for the value of qft 
since it has not been set to anything. That is what the message "local 
variable 'qft' referenced before assignment' means.


 


   if ft.count()>=2:
   aqft=ft.aggregate(sum('percentage'))
   return u'%d'(aqft)


Note you'll never get to this code since you unconditionally return in 
the line above it. It also looks like it has the same problem of the 
code above, in that it sets the variable in a conditional block but 
then the return statement that uses the variable value isn't in that 
block. Perhaps you'll never have the same issue, since the cases where 
you would not take the conditional branch have already been dealt with 
above, but if that's the case -- if your code by this point has 
already ensured that ft.count() must be >= 2 then that conditional 
ought not be there at all.


Once you get past the error referencing a variable that has not been 
set, you are going to hit another problem with all of those return 
statements: the compiler, when it tries to run any of them, is going 
to report TypeError: 'unicode' object is not callable. If you are 
trying to return a unicode string containing the value you need to put 
the interpolation operator % in between the string and values you want 
to embed in it: u'%d' % qft.


Beyond that, this whole routine looks not quite right. I don't have 
time to figure out what it is exactly you are trying to calculate, but 
whatever it is your code should not need to have different legs for 
the case where there are 0, 1, or more than 1 related things. If you 
need a sum of values from the related things the code to get it should 
be the same regardless of how many 

Re: 'if' statement improperly formatted

[vamsy krishna]

I've added the smart if feature to my custom template tags to get this
working.

On Jan 23, 7:05 pm, vamsy krishna  wrote:
> Oh ok. Thanks for the direction. The server on which it fails uses
> django 1.1. I was looking through the documentation for the same and
> did not find anything related to relational operators in the django
> templates. Any idea how can I do  '<', '>' in 1.1?
>
> On Jan 23, 6:39 pm, Karen Tracey  wrote:
>
> > On Sun, Jan 23, 2011 at 8:25 AM, vamsy krishna 
> > wrote:
>
> > > I'm getting the below exception from the third line in the snippet.
> > > This works fine on one server while fails on the other. Any help?
>
> > > Exception Type:         TemplateSyntaxError
> > > Exception Value:        'if' statement improperly formatted
>
> > >                                        {% range 1:32 as i %}
> > >                                                {% ifequal i curdattime.day
> > > %}
> > >                                                        {% if i < 10 %}
>
> > That's the error message you get if you try to use "smart" if (a Django 1.2
> > feature:http://docs.djangoproject.com/en/1.2/releases/1.2/#smart-if-tag)
> > with an earlier release of Django. You either need to stick to the if tag
> > syntax supported by your lower-level release or upgrade your Django install
> > to 1.2.
>
> > Karen
> > --http://tracey.org/kmt/

-- 
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: 'if' statement improperly formatted

[vamsy krishna]

Oh ok. Thanks for the direction. The server on which it fails uses
django 1.1. I was looking through the documentation for the same and
did not find anything related to relational operators in the django
templates. Any idea how can I do  '<', '>' in 1.1?

On Jan 23, 6:39 pm, Karen Tracey  wrote:
> On Sun, Jan 23, 2011 at 8:25 AM, vamsy krishna wrote:
>
> > I'm getting the below exception from the third line in the snippet.
> > This works fine on one server while fails on the other. Any help?
>
> > Exception Type:         TemplateSyntaxError
> > Exception Value:        'if' statement improperly formatted
>
> >                                        {% range 1:32 as i %}
> >                                                {% ifequal i curdattime.day
> > %}
> >                                                        {% if i < 10 %}
>
> That's the error message you get if you try to use "smart" if (a Django 1.2
> feature:http://docs.djangoproject.com/en/1.2/releases/1.2/#smart-if-tag)
> with an earlier release of Django. You either need to stick to the if tag
> syntax supported by your lower-level release or upgrade your Django install
> to 1.2.
>
> Karen
> --http://tracey.org/kmt/

-- 
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: 'if' statement improperly formatted

[Karen Tracey]

On Sun, Jan 23, 2011 at 8:25 AM, vamsy krishna wrote:

> I'm getting the below exception from the third line in the snippet.
> This works fine on one server while fails on the other. Any help?
>
> Exception Type: TemplateSyntaxError
> Exception Value:'if' statement improperly formatted
>
>{% range 1:32 as i %}
>{% ifequal i curdattime.day
> %}
>{% if i < 10 %}
>

That's the error message you get if you try to use "smart" if (a Django 1.2
feature: http://docs.djangoproject.com/en/1.2/releases/1.2/#smart-if-tag)
with an earlier release of Django. You either need to stick to the if tag
syntax supported by your lower-level release or upgrade your Django install
to 1.2.

Karen
-- 
http://tracey.org/kmt/

-- 
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 + cherokee configuration problem

[km]

On Sun, Jan 23, 2011 at 6:42 PM, Ivo Brodien  wrote:

>
> 1) Accessing http://localhost/myproject  displays the whole hierarchy of
> files in the "myproject" which is not what i want to display.
>  so how do i make "index" function in myapp/views.py render base.html
> as before with cherokee ?
>
>
> looks like you put your django project root as the path for static root
> instead of to mymedia? check your dir settings in the virtual server.
>
> No.
The "document root" of the virtual server points to /path/to/mymedia
and the django project root points to /path/to/myproject
but still i have the same issue.
regards,
KM


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

Some Questions

[HOYAJIGI]

1, Is it possible to use NoSQL(HBase or Cassandra) rather than SQL
server in Django?

2. Is there any web log analysis "middleware" for django?
   If not why not make one?

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

Confused by __unicode_cast and __str_cast in django.utils.functional

[Kevin Xiao]

Hi,

I am stuck while look into source code of Django's lazy decorator. At
line 205 of functinal.py, there is:

 def __unicode_cast(self):
return self.__func(*self.__args, **self.__kw)

 def __str_cast(self):
return str(self.__func(*self.__args, **self.__kw))

Why doesn't __unicode_cast function need to call *unicode* on
*self.__func(...)* like what __str_cast does,call *str* function?

Any help is appreciated.

Kevin Xiao

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

32-bit integers IP address to 4-octet IP address

[Phillip Bailey]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Dear All,

I've started playing around with Django in the last few days, and I'm
enjoying the speed
and the power of such framework. I'm writing a small application to
display and sort
ip addresses stored in a Postgresql database, right now I'm stuck with
32-bit integers
IP address translated to 4-octet IP address .

Here's the the class of the ip address.

class Iphdr(models.Model):
sid = models.IntegerField(primary_key=True)
cid = models.BigIntegerField(primary_key=True)
ip_src = models.BigIntegerField()
ip_dst = models.BigIntegerField()
ip_ver = models.SmallIntegerField()
ip_hlen = models.SmallIntegerField()
ip_tos = models.SmallIntegerField()
ip_len = models.IntegerField()
ip_id = models.IntegerField()
ip_flags = models.SmallIntegerField()
ip_off = models.IntegerField()
ip_ttl = models.SmallIntegerField()
ip_proto = models.SmallIntegerField()
ip_csum = models.IntegerField()
class Meta:
db_table = u'iphdr'


As the IP addresses are stored in the database as unsigned 32-bit
integers, so when I
run  ip = Iphdr.objects.values("ip_src") the result is in 32-bit integers,

{'ip_src': 3251031814L}{'ip_src': 3251031816L}{'ip_src': 3251031816L}
{'ip_src': 3251031816L}{'ip_src': 3251031814L}{'ip_src': 3251031816L}

There's any elegant solution that can translate 32-bit integers to
4-octet IP address (192.168.1.88) ?

Thanks in advance.

Phillip
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJNO++eAAoJENNBJKHbaDgTM0cH/0/QjdPTi53tJG4YhjVpt6oj
cJk6rAEHwFha//Vby4lH2sT+ZyKmv+UAjSVmvBCptXBOcm5LuedMmMCVeInfuliQ
GeOPlQ4nvrZSbcdXirLu9Jqa+Yqj6nalGF7i0WetqvdsdrkQQdrcx1D814DSZKGq
qQWpdyVEmdrRSfiOUvrYbnXDCnTwCXZdUhcpDNmD+5h9S2/uiMzP5cM2wtfMg1hO
swYS9B7h/6vAd1ekOZh+ij2X4mszUfp5rQzFjCXtYnQma8pN+58UMpWwYVKj2FzA
tgRaWC1Qz4hWsXRvwirqo/ZtyJMWxkOdwVaxl3iug/NCGW/yDCMa97zweYOHKCs=
=W+IC
-END PGP SIGNATURE-

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



0xDB683813.asc
Description: application/pgp-keys

Why I cannot save an object in administration?

[Flo]

Hi all,

I'm a new comer to Django. As a first step, I use Django
Administration to manage my objects. But whenever I added or changed
an object(or a user, the same thing), then click the "Save" button,
the page just jumped to an error page, which said "the page cannot be
displayed". It seems that Django redirected the page to an unkonw
site.

I'm using Django 1.2.4 & Python 2.6.6 in WinXP.

Any help will be highly appreciated. Thanks!!

Flo

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

'if' statement improperly formatted

[vamsy krishna]

Hi,

I'm getting the below exception from the third line in the snippet.
This works fine on one server while fails on the other. Any help?

Exception Type: TemplateSyntaxError
Exception Value:'if' statement improperly formatted

{% range 1:32 as i %}
{% ifequal i curdattime.day %}
{% if i < 10 %}
0{{i}}
{% else %}
{{i}}
{% endif %}
{% else %}
{% if i < 10 %}
0{{i}}
{% else %}
{{i}}
{% endif %}
{% endifequal %}
{% endrange %}

P.S: "range" is a custom tag which I've picked up online for range
looping in the template.

-- 
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 Deployment Statistics (via djangosites.org)

[Aryeh Leib Taurog]

On Jan 23, 7:03 am, Ross Poulton  wrote:
> Hello fellow Django users,
>
> A long time ago I started collecting deployment information from
> Django users submitting their websites towww.djangosites.org. I
> promised at the time to make the stats public, and although i've
> shared them with a few I've never made it public that the stats are
> available.
>
> Firstly, sorry for taking so long to give this back to the community.
>
> The stats can be found online athttp://www.djangosites.org/stats/.
> There's a link in the DjangoSites header to it. A few findings that
> are obvious from a few minutes on the above page:
>
> 1) MySQL powers over half of the websites listed. Postgres around a
> third, SQLite 1 in 10.
> 2) Apache is still king of the hill. nginx and Lighty share around 20%
> of the install base
> 3) Interestingly, IIS is being used in almost no deployments according
> to our stats, even though MSSQL still gets a look-in.
> 4) mod_python isn't as big as it once was; mod_wsgi is the preferred
> Django serving method by a long shot. mod_python and fastcgi each
> count for ~20%
> 5) In our userbase, less than 10% of deployments are on something
> other than a Linux variant.
>
> These stats will continue to evolve over time as more websites are
> submitted and as current ones are updated. I'm keeping time-based
> stats on these as well so that one day we can show how this usage has
> changed over time. Hopefully I get around to that sooner than I got to
> these :)
>
> Thank you to everybody who has submitted websites and provided this
> deployment information. I hope these statistics are useful for you.
> Feedback is welcome via email (r...@rossp.org) or Twitter
> (@RossPoulton). I would love to hear what you have to say!


Thanks!  I'm surprised that so few are running on google app engine; I
would have expected google's user base to be significantly larger than
windows'.

p.s. Could you add permalinks/id attributes to the  elements
please?

-- 
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 + cherokee configuration problem

[Ivo Brodien]

> 1) Accessing http://localhost/myproject  displays the whole hierarchy of 
> files in the "myproject" which is not what i want to display.
>  so how do i make "index" function in myapp/views.py render base.html as 
> before with cherokee ? 

looks like you put your django project root as the path for static root instead 
of to mymedia? check your dir settings in the virtual server.

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

django + cherokee configuration problem

[km]

Hi all,
I am running django (1.2.4) project ("myproject") with an app called
"myapp". The tree looks this way:

myproject
|-- __init__.py
|-- myapp
|   |-- __init__.py
|   |-- models.py
|   |-- templates
|   |   |-- base.html
|   |   |-- base_menu.html
|   |-- tests.py
|   |-- views.py
|-- manage.py
|-- settings.py
|-- urls.py
|-- mymedia
|   |-- css
`-- js

I also have a "templates" dir in "myapp" to hold templates rendered by views
defined in myapps/views.py. Forexample, I could sucessfully render base.html
from "templates" dir using "index" view defined in myapp/views.py when url
http://localhost:8000/index is  accessed. So far so good.

I am porting this  "myproject" to work with cherokee (1.0.18 ppa) on ubuntu
10.10 with python2.6.6.

Cherokee web configuration:
I have defined a virtualhost and  set the "document root" to
/path/to/myproject/mymedia for It hosts jquery and other css to decorate
base.html
I notice two workers on different ports handling csgi protocol: "python
/path/to/myproject/manage.py runfcgi protocol=scgi host=127.0.0.1
port=57698"
I have followed the config settings as defined at
http://www.cherokee-project.com/doc/cookbook_django.html using SCGI

1) Accessing http://localhost/myproject  displays the whole hierarchy of
files in the "myproject" which is not what i want to display.
 so how do i make "index" function in myapp/views.py render base.html as
before with cherokee ?
2) I find only empty logs  in /var/log/cherokee/*.log  and unable to find
the cherokee errors if any. how do i find them ?
3) Do I have to  modify dir/file permissions to "myproject" recursively to
make it work ?
4) The virtual host defined name does not work (viz., www.example.com) when
used as url in a browser.
5) How do I display (render)  "myproject" on the browser using
http://localhost/myproject OR http://www.example.com ? which is the correct
way ?

pls let me know

regards,
KM

-- 
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: Hyphens in Django app/project names?

[Russell Keith-Magee]

On Tue, Jan 18, 2011 at 8:42 AM, Victor Hooi  wrote:
> Russ,
> Aha, excellent, thanks for clearing that up =).
> I can see you point - django-registration has a module called
> "registration", django-extensions has a module called "django_extensions",
> and django-staticfiles has one called "staticfiles". So it seems like I
> either go for a single-word module name, or replace hyphens with
> underscores.
> Is there any recommendation from the Django team? Is sing underscores as
> faux-hyphens considered bad practice?

The only recommendation I would make is that the name you choose is
essentially the interface to your api, so make it easy to use.

django_foobar is accurate, but a PITA if you have to type it every
time you import/use the app, especially if foobar isn't likely to be
inaccurate in the circumstances.

Yours,
Russ Magee %-)

-- 
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: Questions - Django -- Bash problem

[Łukasz Rekucki]

On 23 January 2011 11:54, Kimberly  wrote:
> Hello, I have another question. When it comes to Django, I notice some
> people type as django-admin startproject project and some have to type
> as django-admin.py startproject project ( in my case, I had to do
> that), is it base on the setup of the Django that cause the
> differences between the admin.py and admin?

Django provides the script as "django-admin.py"; Some Linux
distributions (like Ubuntu) package Django with the script renamed to
"django-admin". So that's the cause of the difference and it's not
something that Django has any influence on.

>
> Also, on the command line, I typed " manage.py startapp tolls"  after
> being side my project directory and now it says bash: manage.py:
> command not found

Yes, because that's how bash works. If the script is not on PATH, then
bash won't find it. If you want to run a script from current
directory:

./manage.py startapp tolls

Note, that the file has to be executable, for this to work (it's not
by default). That's why Django's tutorial suggests writing:

python manage.py startapp tolls

To avoid the need of explaining about bash, permission, etc.

>
> I've checked the directory I am using and the manage.py file is there.
> I also set the _init_.py to where the operating system - os is
> imported and that the django_setting_module is set to settings. Any
> advices will be greatly appreciated. Thanks!
>

-- 
Łukasz Rekucki

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

[Mark Penix]

your whole engine line should read
'ENGINE': 'django.db.backends.sqlite3'

-- 
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: Questions - Django -- Bash problem

[Robbington]

Hello Kimberly,

The reason you are getting bash error, is the command you are looking
for is "django-admin.py startapp tolls" not "manage.py startapp
tolls".

Rob

-- 
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: Readonly on subset of forms in Admin inlines

[Peter Phillips]

Thanks for the reply!

I probably didn't explain the problem properly. I have been using the
ModelAdmin.readonly_fields option, however it hasn't been doing quite
what I need for inline formsets. In the case of my inline form, when I
set some of the fields to readonly, they end up read only for all
forms in the formset. That is, every new row that's added to the
inline formset and all existing ones end up with read only fields.
What I was hoping to do was override a method to dynamically set some
fields as read only, but only for some of the forms in the inline
formset, not all of them.

The following code means that once a row/form in the inline was not
created by the request.user, all rows/forms become readonly. What I'd
like is to have fields only in the rows they did not create be
readonly, leaving the ones that they did create editable.

I wasn't sure whether there was perhaps an easy way to loop through
the forms in the inline formset and set options in the admin for each
of them separately.

class IssuesInline(admin.TabularInline):
model = Issues
extra = 0
can_delete = False
fields = ('risk', 'issue', 'priority', 'l1', 'c1', 'notes')
exclude = ('added_by', 'modified_by')
readonly_fields = ('lbyc')

def get_readonly_fields(self,request,obj=None):
if request.user.username!=obj.added_by:
 return ('risk', 'issue', 'priority', 'l1', 'c1',
'notes',) + self.readonly_fields
return self.readonly_fields

Thanks again!

On Jan 20, 8:24 pm, Thomas  wrote:
> Am 20.01.2011 um 03:27 schrieb Peter Phillips:
>
> > Hello,
>
> > Is there a straightforward way to set fields to read only for a subset
> > of the forms in an inline formset in the Admin? I'd like to set some
> > fields to read only on my inline form for rows that were not created
> > by the user. However, when I set the fields to read only, it of course
> > affects all rows/forms in the inline, preventing the user from editing
> > their own rows. Do I need to do a custom formset for
> > InlineModelAdmin.formset?
>
> hi,
>
> maybe this provides a proper solution for 
> you:http://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contri...
>
> good luck,
> TR
>
> 
>
> http://thoreg.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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Questions - Django -- Bash problem

[Kimberly]

Hello, I have another question. When it comes to Django, I notice some
people type as django-admin startproject project and some have to type
as django-admin.py startproject project ( in my case, I had to do
that), is it base on the setup of the Django that cause the
differences between the admin.py and admin?

Also, on the command line, I typed " manage.py startapp tolls"  after
being side my project directory and now it says bash: manage.py:
command not found

I've checked the directory I am using and the manage.py file is there.
I also set the _init_.py to where the operating system - os is
imported and that the django_setting_module is set to settings. Any
advices will be greatly appreciated. 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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Django Improper Configuration

[Kimberly]

Hello! I have a problem with the Django. I was able to create django-
admin.py startproject project in my home directory, and was able to
see the files such as manage.py, init.py, settings.py, and so on.
After some steps, I approached a problem with manage.py syncdb. It
says that the database ENGINE setting has not been set.

In the settings.py, I've set the database engine like this :

ENGINE = ' sqlite3'. So I am confused on why it says that it has not
been set when it has been? I must be overlooking something here.

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