Re: Issue in Django 1.7.1 with __unicode__ and admin site?

[Krishnakant Mane]

On 11/12/2014 03:21 AM, donarb wrote:

On Tuesday, November 11, 2014 1:26:53 PM UTC-8, krmane wrote:


That brings me to another related question.
I had asked this before but let's put it in a different way.
With the official Django tutorial for 1.7, they say it is ment for
Python 3X.
Do we have any plan to have some appendix on using the same tutorial for
Python 2.7x?
Like to have this code working with 2.7 do XYZ instead of ABC.
Happy hacking.
Krishnakant.On 11/12/2014 01:56 AM, Jorge Andrés Vergara Ebratt wrote:

When you are in Python3 you don't use __unicode__ you use __str__

On Tue, Nov 11, 2014, 3:14 PM Arjan de Knegt 

wrote:


I am using Django 1.7.1 with python 3.4.0 for my latest project.
I am working on a model called Song. In the admin site all object that

I

add show as "Song object" where I would expect the title of the Song. I
have added __unicode__ to the model. is there something I miss or are
things changed in Django 1.7? Below the model and what is shown in the
admin site

*Model:*
class Song(models.Model):
  title = models.CharField(max_length=100, verbose_name = 'Titel')
  author = models.CharField(max_length=100, verbose_name = 'Auteur')
  genre = models.ForeignKey('Genre', to_field='genre')
  featured = models.BooleanField(default = False, verbose_name =
'featured')
  song_order = models.IntegerField()

  class Meta:
  verbose_name = _('Song')
  verbose_name_plural = _('Songs')
  ordering = ['song_order']

  def __unicode__(self):
  return self.title

*Shown in Admin site:*
   Song
Song object  Song

object

 Song object
 Song object


--
You received this message because you are subscribed to the Google

Groups

"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send

an

email to django-users...@googlegroups.com .
To post to this group, send email to django...@googlegroups.com

.

Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit


https://groups.google.com/d/msgid/django-users/01cc75ba-302c-4066-9e4a-fbdc4f3504ea%40googlegroups.com

<

https://groups.google.com/d/msgid/django-users/01cc75ba-302c-4066-9e4a-fbdc4f3504ea%40googlegroups.com?utm_medium=email_source=footer>


.
For more options, visit https://groups.google.com/d/optout.




It's better to start another thread rather than hijacking a thread.
Otherwise, people who have the same question as you can't tell by looking
at the title of this post. But to answer your question, the comments at the
start of the tutorial read as follows:

*If you are still using Python 2.7, you will need to adjust the code
samples slightly, as described in comments.*



And  where are the comments?
 am sorry if I am seriously missing some text.
happy hacking.
Krishnakant.

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5463002C.2090701%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Swampdragon, the realtime framework for Django seems interesting. But will it scale ?

[Kakar Nyori]

Oooh! Nice one. But its very new though. I would also like to hear from the
experts!!! Thanks for the post though

On Wed, Nov 12, 2014 at 10:07 AM, Suren Sth  wrote:

> I recently came across Swampdragon ( Visit official site
> ). I am curious can it be used in production
> sites and will it scale ? If it can be, what is the best way?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/74092e59-801e-48f6-ba99-9d6231516b84%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CA%2B8oko%2BJX98KnUG9erPqHiKtBYLkKypVg32pmeR-dcG5__dVhA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django + Database Connections

[Kakar Nyori]

Very nicely explained.

On Wed, Nov 12, 2014 at 2:55 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> Hi Edward,
>
> On Tue, Nov 11, 2014 at 12:30 AM, Edward Armes 
> wrote:
>
>> Hi there,
>>
>> I am currently looking at Django for a personal project. While I
>> understand how a lot of it works I can't wrap my head around how the actual
>> DB querying is done specifically what part of Django actually looks at the
>> database (I'm not talking about Manager, Models or Querysets, but the
>> actual parts of Django that use the ORM's to get data from the database
>> itself).
>>
>> If a reason is required without going into detail on my current
>> half-baked idea, I'm specifically looking how to handle database operations
>> that have a significant return time by marrying asynchronous environments
>> with synchronous ones. While it may be more efficant to use a non-Django
>> database handler. For now I want to look into using the Django framework
>> without needing additional imports.
>>
>>
> It's not that a *reason* is required - it's that it's not entirely clear
> what you're asking for.
>
> The thing is, Django *itself* doesn't do a lot of querying - Django is a
> template system, and a forms layer, and a database ORM, all nicely
> integrated, so you can easily compose the pieces to do something useful.
> There are places where the forms layer will issue queries (e.g., if you
> want to display a form that has a  representing the available
> options from a model), but that's really at the level of "give me a
> queryset that represents the options I want to display".
>
> The only part of Django *itself* that "uses" Django is the contents of the
> contrib apps - most importantly, contrib.admin, but there are others.
>
> The idea of marrying async and synchronous environments isn't a new one -
> it was the subject of a Google Summer of Code project this year, the result
> of which will hopefully be committed to trunk for 1.8. The core of that
> project was to formalise the API around Django's model layer so that you
> can write a "duck typed" object that will be a substitute for a Django
> model (subject to certain constraints and limitations). Search the
> Django-Developer archive for "Meta Refactor" if you want more details.
> However, that won't let you get away "without needing additional imports" -
> at some point, you're going to need to import your async layer, because
> Django doesn't have one.
>
> I don't know if any of this helps... hopefully it does :-)
>
> Yours,
> Russ Magee %-)
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CAJxq848_Oy_oWhLnu5h8dfgT1MW8CKny_ZQKZcQ4nCdO9_W%2B5g%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CA%2B8oko%2BZquCXnCV5k9WRMevYRMX4Unca_EhimKTQdCCcuzqQAA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Swampdragon, the realtime framework for Django seems interesting. But will it scale ?

[Suren Sth]

I recently came across Swampdragon ( Visit official site 
). I am curious can it be used in production sites 
and will it scale ? If it can be, what is the best way?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/74092e59-801e-48f6-ba99-9d6231516b84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Loading fixtures in Django 1.7

[André Manzano]

Leonard, try that.

http://stackoverflow.com/questions/25960850/loading-initial-data-with-django-1-7-and-data-migrations


Att,
Andre Manzano




Em terça-feira, 11 de novembro de 2014 13h36min14s UTC-2, Leonard Wayne 
escreveu:
>
> Fred,
>
> Got it!!  Thank you!!
>
> - Leonard
>
> On Sunday, November 9, 2014 5:46:30 PM UTC-5, Leonard Wayne wrote:
>>
>> I am in the process of upgrading from
>> Django 1.6 to 1.7.
>>
>> I have three fixtures.  I am trying to figure
>> out how I should load them.
>>
>> One fixture is `initial_data.json`, and I know
>> that starting with Django 1.7 this special
>> fixture no longer gets automatically loaded
>> as it did when we used to run `syncdb` (i.e.,
>> prior to deprecation in Django 1.7).
>>
>> So I know all three fixtures should be loaded
>> the same way as each other, whatever way that
>> may be.
>>
>> My main question is:
>>
>> Should I keep using `loaddata`, as in:
>>
>> python manage.py loaddata .json
>>
>> Reading the documentation I get the sense
>> (though I am not sure) that now the preferred
>> approach to load fixtures is to create a
>> migration to perform the loading.  But I
>> don't see an example of how to do this
>> process from beginning to end.  It looks
>> like the process starts with creating an
>> empty migration, then manually editing the
>> migration file to define a function like:
>>
>> def load_data(apps, schema_editor):
>>
>> But I don't know how to write this function
>> (`load_data`), and I can't find an example.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/539e3fb7-f699-45c1-bb19-a814aa7231c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Chrome Desktop Notification for Django

[Max Nathaniel Ho]

I found this excellent example on Chrome Desktop Notification - Chrome 
desktop notification example? 


I am able to create the Desktop Notification by clicking a button. 

However, that is pretty front-end. 

I would like to find out how to link an event in the web app. For example, 
 the event could be someone posting a job for a freelance work. And user 
who is logged into the web app but not actively browsing on the web page 
will be notified via the Chrome Desktop Notification. 

Are there any examples of how I can create a Event Handler to listen to 
data in the backend, and prompt the user via the Desktop Notification?

Many thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/7e07f9eb-1009-4bc2-b254-7f2637231284%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Import Error Module

[Niall]

Hi Erik, yes it is installed but it comes up with the following error when 
I try to run the server again.

I know that it is something simple like changing the PYTHONPATH so if you 
could advise on why it is happening and how I should proceed that would be 
great. 


Nialls-MBP-2:fest-api-master niallconway$ python manage.py

Traceback (most recent call last):

  File "manage.py", line 9, in 

execute_from_command_line(sys.argv)

  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/__init__.py",
 
line 385, in execute_from_command_line

utility.execute()

  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/core/management/__init__.py",
 
line 345, in execute

settings.INSTALLED_APPS

  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/conf/__init__.py",
 
line 46, in __getattr__

self._setup(name)

  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/conf/__init__.py",
 
line 42, in _setup

self._wrapped = Settings(settings_module)

  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/django/conf/__init__.py",
 
line 98, in __init__

% (self.SETTINGS_MODULE, e)

ImportError: Could not import settings 'configs.settings' (Is it on 
sys.path? Is there an import error in the settings file?): No module named 
settings









On Wednesday, 12 November 2014 01:07:19 UTC+10, Erik Cederstrand wrote:
>
> > Den 11/11/2014 kl. 15.48 skrev Niall : 
>
> > 
> > Hello, I was hoping that anyone could please advise me on a very simple 
> issue which I am having regarding running the dev server (see attachments). 
> I am receiving the following import error when attempting to run. 
> > 
> > ImportError: No module named django.core.management 
>
> Do you have django installed? Try running: 
>
> python -c "import django;" 
>
> If not, run "pip install django" 
>
> Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/eb961a1c-195a-487d-a727-43290b6861e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: how to test an application that's using a legacy database

[Carl Meyer]

Hi David,

On 11/11/2014 08:37 AM, dpalao.pyt...@gmail.com wrote:
> Dear Carl,
> 
> Thank you for the answer.
> 
> On Tuesday, November 11, 2014 3:13:18 PM UTC+1, Carl Meyer wrote:
> 
> Hi David,
> 
> On 11/11/2014 07:01 AM, dpalao...@gmail.com  wrote:
> > I see your point. You might be right, but it is not clear to me
> how to
> > do it and if it would work: I have already tried to subclass
> > DiscoverRunner to modify its behaviour with little success.
> 
> If there are specific aspects of "how to do it" that are confusing to
> you, I could try to clarify. Or if you try it and have specific
> problems.
> 
> 
> Well, I never worked with sql directly. And as I said in my post when I
> tried to subclass  DiscoverRunner I got the impression that it is not
> straightforward (at least for my limited experience with Django).
> 
> > Another problem that I see: it is not an homogenous approach. I mean,
> > the models are created from the production database. Now I create an
> > independent database for testing. Of course, you will tell me that I
> > have to follow the TDD approach to the end: for the code that creates
> > the testing database too! And I would agree. But it is clearly a
> bit too
> > complicated.
> 
> I'm afraid I am quite confused by this paragraph.
> 
> I don't know what you mean by "not an homogenous approach".
> 
> And I don't know what you mean by "the models are created from the
> production database."
> 
> And I don't know what you mean by "an independent database for
> testing."
> Django already creates a new database for each test run. I'm not
> suggesting creating any additional database beyond that, just running
> some SQL to create your legacy (un-managed) tables in the testing
> database.
> 
> The code that creates the testing database will be exercised at the
> start of every test run, and if it's not working your tests will fail
> because the legacy tables are not created. Personally, I'd consider
> that
> adequate; I wouldn't write any additional tests for that code.
> 
> 
>  I created the models by running "inspectdb". I see that as a (logical)
> link between the models and the tables. Perhaps not the standard link,
> but they are related. That is what I meant by "the models are created
> from the production database".

I see, that makes sense.

> Now your suggestion is to create some tables from scratch. By hand. This
> is what I mean by "not an homogeneous approach", because I don't see a
> logical link between the models and the testing database. The testing
> database is created by me. (Or by Django, then I take control to create
> the tables, then I return control to Django -- if this is what you suggest).

Sorry, I didn't fully explain this part of my suggestion. I would not
create the SQL for those tables "by hand" - I would do it via a dump of
the SQL schema from the actual production tables.

> But actually I think your solution makes a lot of sense. At the
> beginning I wanted Django to create the testing database along with the
> tables automatically. And you probably are right and the SQL code to
> create the tables is absolutely trivial, but for me it is not.
> So I tried also something slightly different. As the database already
> exists, I think it would make sense if I also the testing database
> exists prior to testing.
> What I just did was:
> I created the testing database simply with a command like
> 
> mysqldump -u user --password='xxx' -h localhost -d production_db | mysql
> -h localhost -u user --passwor='xxx' -Dtest_db

So this is close to my suggestion. But rather than creating the entire
DB (including managed models too), I would send the dump to a SQL file
instead:

mysqldump -u user --password='xxx' -h localhost -d production_db >
schema.sql

And then edit schema.sql to remove any tables for normal managed models,
leaving only the table definitions for the unmanaged (legacy) tables.
(You might also add `--no-data`, depending whether you want your legacy
tables to also be prepopulated with data for your tests).

Then you can allow Django to create its test database normally, and run
migrations to create tables for your managed models; you just have to
additionally run `schema.sql` to add in the un-managed tables.

(It's possible that your approach of pre-creating the entire test DB
could just work, with no need to subclass DiscoverRunner at all, by
using the --keepdb option to manage.py test; but that option only exists
in the Django development version, so you probably don't have it.)

> Again, I must subclassing DiscoverRunner to have a chance to succeed
> (need to by-pass db creation), and actually Django complains if I don't
> do that.
> So, I subclassed the DiscoverRunner like this
> 
> class SkipDBCreationDiscoverRunner(DiscoverRunner):
> def setup_databases(self, **kwargs):
> return
> 
> def 

Re: Issue in Django 1.7.1 with __unicode__ and admin site?

[Mike Dewhirst]

On 12/11/2014 7:26 AM, Jorge Andrés Vergara Ebratt wrote:

When you are in Python3 you don't use __unicode__ you use __str__


You can leave __unicode__ in place for Python 2.x and add ...

def __str__(self):
return self.__unicode__()

... to satisfy Python 3.x at the same time



On Tue, Nov 11, 2014, 3:14 PMÂ Arjan de Knegt > wrote:

I am using Django 1.7.1 with python 3.4.0 for my latest project.
I am working on a model called Song. In the admin site all object
that I add show as "Song object" where I would expect the title of
the Song. I have added __unicode__ to the model. is there something
I miss or are things changed in Django 1.7? Below the model and what
is shown in the admin site

_Model:_
class Song(models.Model):
    title = models.CharField(max_length=100, verbose_name = 'Titel')
    author = models.CharField(max_length=100, verbose_name =
'Auteur')
    genre = models.ForeignKey('Genre', to_field='genre')
    featured = models.BooleanField(default = False, verbose_name
= 'featured')
    song_order = models.IntegerField()
Â
    class Meta:
        verbose_name = _('Song')
        verbose_name_plural = _('Songs')
        ordering = ['song_order']

    def __unicode__(self):
        return self.title

_Shown in Admin site:_

Song
Song object 
Song object 
Song object 
Song object 


--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to django-users+unsubscr...@googlegroups.com
.
To post to this group, send email to django-users@googlegroups.com
.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit

https://groups.google.com/d/msgid/django-users/01cc75ba-302c-4066-9e4a-fbdc4f3504ea%40googlegroups.com

.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-users+unsubscr...@googlegroups.com
.
To post to this group, send email to django-users@googlegroups.com
.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/CAAeX05F%3DOUMswk2KQfdLvkrEGkQ9PbztLYBbC44T66WU%2BAYMYw%40mail.gmail.com
.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/546296F2.5060201%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.

Re: Issue in Django 1.7.1 with __unicode__ and admin site?

[donarb]

On Tuesday, November 11, 2014 1:26:53 PM UTC-8, krmane wrote:
>
>
> That brings me to another related question. 
> I had asked this before but let's put it in a different way. 
> With the official Django tutorial for 1.7, they say it is ment for 
> Python 3X. 
> Do we have any plan to have some appendix on using the same tutorial for 
> Python 2.7x? 
> Like to have this code working with 2.7 do XYZ instead of ABC. 
> Happy hacking. 
> Krishnakant.On 11/12/2014 01:56 AM, Jorge Andrés Vergara Ebratt wrote: 
> > When you are in Python3 you don't use __unicode__ you use __str__ 
> > 
> > On Tue, Nov 11, 2014, 3:14 PM Arjan de Knegt  > 
> > wrote: 
> > 
> >> I am using Django 1.7.1 with python 3.4.0 for my latest project. 
> >> I am working on a model called Song. In the admin site all object that 
> I 
> >> add show as "Song object" where I would expect the title of the Song. I 
> >> have added __unicode__ to the model. is there something I miss or are 
> >> things changed in Django 1.7? Below the model and what is shown in the 
> >> admin site 
> >> 
> >> *Model:* 
> >> class Song(models.Model): 
> >>  title = models.CharField(max_length=100, verbose_name = 'Titel') 
> >>  author = models.CharField(max_length=100, verbose_name = 'Auteur') 
> >>  genre = models.ForeignKey('Genre', to_field='genre') 
> >>  featured = models.BooleanField(default = False, verbose_name = 
> >> 'featured') 
> >>  song_order = models.IntegerField() 
> >> 
> >>  class Meta: 
> >>  verbose_name = _('Song') 
> >>  verbose_name_plural = _('Songs') 
> >>  ordering = ['song_order'] 
> >> 
> >>  def __unicode__(self): 
> >>  return self.title 
> >> 
> >> *Shown in Admin site:* 
> >>   Song 
> >>Song object  Song 
> object 
> >>  Song object 
> >>  Song object 
> >>  
> >> 
> >> -- 
> >> You received this message because you are subscribed to the Google 
> Groups 
> >> "Django users" group. 
> >> To unsubscribe from this group and stop receiving emails from it, send 
> an 
> >> email to django-users...@googlegroups.com . 
> >> To post to this group, send email to django...@googlegroups.com 
> . 
> >> Visit this group at http://groups.google.com/group/django-users. 
> >> To view this discussion on the web visit 
> >> 
> https://groups.google.com/d/msgid/django-users/01cc75ba-302c-4066-9e4a-fbdc4f3504ea%40googlegroups.com
>  
> >> <
> https://groups.google.com/d/msgid/django-users/01cc75ba-302c-4066-9e4a-fbdc4f3504ea%40googlegroups.com?utm_medium=email_source=footer>
>  
>
> >> . 
> >> For more options, visit https://groups.google.com/d/optout. 
> >> 
>
>
It's better to start another thread rather than hijacking a thread. 
Otherwise, people who have the same question as you can't tell by looking 
at the title of this post. But to answer your question, the comments at the 
start of the tutorial read as follows:

*If you are still using Python 2.7, you will need to adjust the code 
samples slightly, as described in comments.*

 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/99931953-6f0e-4bc2-a82b-499e580d9831%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Looking for Django Python Developers to build Strong Application

[Ankit Vats]

Hi

I am looking for serious Django Python Developers or a company who can make 
a very powerful ecommerce based site in django and create customized 
environment, 
We have a project which need to build in Django cmd & Django Oscar 
ecommerce platform need to be used. If there is any good Indian Based 
company, please refer some good ones. 
We will use different kinds of technologies on site for e.g. Amazon 
Cloudfront, s3, glacier, pusher app, twilio, mail chimp, mandrill, stripe 
payment gateways, etc. 
Thanks in advance
Ankit

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/e405a6cb-9f3d-4ab0-be60-26c883c62aa6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issue in Django 1.7.1 with __unicode__ and admin site?

[Krishnakant Mane]

That brings me to another related question.
I had asked this before but let's put it in a different way.
With the official Django tutorial for 1.7, they say it is ment for 
Python 3X.
Do we have any plan to have some appendix on using the same tutorial for 
Python 2.7x?

Like to have this code working with 2.7 do XYZ instead of ABC.
Happy hacking.
Krishnakant.On 11/12/2014 01:56 AM, Jorge Andrés Vergara Ebratt wrote:

When you are in Python3 you don't use __unicode__ you use __str__

On Tue, Nov 11, 2014, 3:14 PM Arjan de Knegt 
wrote:


I am using Django 1.7.1 with python 3.4.0 for my latest project.
I am working on a model called Song. In the admin site all object that I
add show as "Song object" where I would expect the title of the Song. I
have added __unicode__ to the model. is there something I miss or are
things changed in Django 1.7? Below the model and what is shown in the
admin site

*Model:*
class Song(models.Model):
 title = models.CharField(max_length=100, verbose_name = 'Titel')
 author = models.CharField(max_length=100, verbose_name = 'Auteur')
 genre = models.ForeignKey('Genre', to_field='genre')
 featured = models.BooleanField(default = False, verbose_name =
'featured')
 song_order = models.IntegerField()

 class Meta:
 verbose_name = _('Song')
 verbose_name_plural = _('Songs')
 ordering = ['song_order']

 def __unicode__(self):
 return self.title

*Shown in Admin site:*
  Song
   Song object  Song object
 Song object
 Song object


--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/01cc75ba-302c-4066-9e4a-fbdc4f3504ea%40googlegroups.com

.
For more options, visit https://groups.google.com/d/optout.



--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/546277F5.9080503%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django + Database Connections

[Russell Keith-Magee]

Hi Edward,

On Tue, Nov 11, 2014 at 12:30 AM, Edward Armes 
wrote:

> Hi there,
>
> I am currently looking at Django for a personal project. While I
> understand how a lot of it works I can't wrap my head around how the actual
> DB querying is done specifically what part of Django actually looks at the
> database (I'm not talking about Manager, Models or Querysets, but the
> actual parts of Django that use the ORM's to get data from the database
> itself).
>
> If a reason is required without going into detail on my current half-baked
> idea, I'm specifically looking how to handle database operations that have
> a significant return time by marrying asynchronous environments with
> synchronous ones. While it may be more efficant to use a non-Django
> database handler. For now I want to look into using the Django framework
> without needing additional imports.
>
>
It's not that a *reason* is required - it's that it's not entirely clear
what you're asking for.

The thing is, Django *itself* doesn't do a lot of querying - Django is a
template system, and a forms layer, and a database ORM, all nicely
integrated, so you can easily compose the pieces to do something useful.
There are places where the forms layer will issue queries (e.g., if you
want to display a form that has a  representing the available
options from a model), but that's really at the level of "give me a
queryset that represents the options I want to display".

The only part of Django *itself* that "uses" Django is the contents of the
contrib apps - most importantly, contrib.admin, but there are others.

The idea of marrying async and synchronous environments isn't a new one -
it was the subject of a Google Summer of Code project this year, the result
of which will hopefully be committed to trunk for 1.8. The core of that
project was to formalise the API around Django's model layer so that you
can write a "duck typed" object that will be a substitute for a Django
model (subject to certain constraints and limitations). Search the
Django-Developer archive for "Meta Refactor" if you want more details.
However, that won't let you get away "without needing additional imports" -
at some point, you're going to need to import your async layer, because
Django doesn't have one.

I don't know if any of this helps... hopefully it does :-)

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAJxq848_Oy_oWhLnu5h8dfgT1MW8CKny_ZQKZcQ4nCdO9_W%2B5g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Issue in Django 1.7.1 with __unicode__ and admin site?

[Jorge Andrés Vergara Ebratt]

When you are in Python3 you don't use __unicode__ you use __str__

On Tue, Nov 11, 2014, 3:14 PM Arjan de Knegt 
wrote:

> I am using Django 1.7.1 with python 3.4.0 for my latest project.
> I am working on a model called Song. In the admin site all object that I
> add show as "Song object" where I would expect the title of the Song. I
> have added __unicode__ to the model. is there something I miss or are
> things changed in Django 1.7? Below the model and what is shown in the
> admin site
>
> *Model:*
> class Song(models.Model):
> title = models.CharField(max_length=100, verbose_name = 'Titel')
> author = models.CharField(max_length=100, verbose_name = 'Auteur')
> genre = models.ForeignKey('Genre', to_field='genre')
> featured = models.BooleanField(default = False, verbose_name =
> 'featured')
> song_order = models.IntegerField()
>
> class Meta:
> verbose_name = _('Song')
> verbose_name_plural = _('Songs')
> ordering = ['song_order']
>
> def __unicode__(self):
> return self.title
>
> *Shown in Admin site:*
>  Song
>   Song object  Song object
>  Song object
>  Song object
> 
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/01cc75ba-302c-4066-9e4a-fbdc4f3504ea%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAAeX05F%3DOUMswk2KQfdLvkrEGkQ9PbztLYBbC44T66WU%2BAYMYw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Modifying a ModelAdmin instance at runtime

[Peter Sagerson]

The documentation of ModelAdmin.get_form()[1] demonstrates modifying 
self.exclude in order to modify the add/change form on a per-request basis. 
However, looking at django.contrib.admin, it seems clear that ModelAdmin is 
instantiated when it's installed, not for every request. It also doesn't 
appear to be a subclass of threading.local. Is there some reason this isn't 
a terrible idea or is the example just in error?

Thanks,
Peter


[1] 
https://docs.djangoproject.com/en/1.7/ref/contrib/admin/#django.contrib.admin.ModelAdmin.get_form

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/06fc9478-c3ac-4ba4-ba18-2ea59c7767f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Issue in Django 1.7.1 with __unicode__ and admin site?

[Arjan de Knegt]

I am using Django 1.7.1 with python 3.4.0 for my latest project.
I am working on a model called Song. In the admin site all object that I 
add show as "Song object" where I would expect the title of the Song. I 
have added __unicode__ to the model. is there something I miss or are 
things changed in Django 1.7? Below the model and what is shown in the 
admin site

*Model:*
class Song(models.Model):
title = models.CharField(max_length=100, verbose_name = 'Titel')
author = models.CharField(max_length=100, verbose_name = 'Auteur')
genre = models.ForeignKey('Genre', to_field='genre')
featured = models.BooleanField(default = False, verbose_name = 
'featured')
song_order = models.IntegerField()
  
class Meta:
verbose_name = _('Song')
verbose_name_plural = _('Songs')
ordering = ['song_order']

def __unicode__(self):
return self.title 

*Shown in Admin site:*
 Song
  Song object  Song object 
 Song object 
 Song object 


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/01cc75ba-302c-4066-9e4a-fbdc4f3504ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: how to test an application that's using a legacy database

[dpalao . python]

Dear Carl,

Thank you for the answer.

On Tuesday, November 11, 2014 3:13:18 PM UTC+1, Carl Meyer wrote:
>
> Hi David, 
>
> On 11/11/2014 07:01 AM, dpalao...@gmail.com  wrote: 
> > I see your point. You might be right, but it is not clear to me how to 
> > do it and if it would work: I have already tried to subclass 
> > DiscoverRunner to modify its behaviour with little success. 
>
> If there are specific aspects of "how to do it" that are confusing to 
> you, I could try to clarify. Or if you try it and have specific problems. 
>
>
Well, I never worked with sql directly. And as I said in my post when I 
tried to subclass  DiscoverRunner I got the impression that it is not 
straightforward (at least for my limited experience with Django).

> Another problem that I see: it is not an homogenous approach. I mean, 
> > the models are created from the production database. Now I create an 
> > independent database for testing. Of course, you will tell me that I 
> > have to follow the TDD approach to the end: for the code that creates 
> > the testing database too! And I would agree. But it is clearly a bit too 
> > complicated. 
>
> I'm afraid I am quite confused by this paragraph. 
>
> I don't know what you mean by "not an homogenous approach". 
>
> And I don't know what you mean by "the models are created from the 
> production database." 
>
> And I don't know what you mean by "an independent database for testing." 
> Django already creates a new database for each test run. I'm not 
> suggesting creating any additional database beyond that, just running 
> some SQL to create your legacy (un-managed) tables in the testing 
> database. 
>
> The code that creates the testing database will be exercised at the 
> start of every test run, and if it's not working your tests will fail 
> because the legacy tables are not created. Personally, I'd consider that 
> adequate; I wouldn't write any additional tests for that code. 
>
>
 I created the models by running "inspectdb". I see that as a (logical) 
link between the models and the tables. Perhaps not the standard link, but 
they are related. That is what I meant by "the models are created from the 
production database".

Now your suggestion is to create some tables from scratch. By hand. This is 
what I mean by "not an homogeneous approach", because I don't see a logical 
link between the models and the testing database. The testing database is 
created by me. (Or by Django, then I take control to create the tables, 
then I return control to Django -- if this is what you suggest).

But actually I think your solution makes a lot of sense. At the beginning I 
wanted Django to create the testing database along with the tables 
automatically. And you probably are right and the SQL code to create the 
tables is absolutely trivial, but for me it is not.
So I tried also something slightly different. As the database already 
exists, I think it would make sense if I also the testing database exists 
prior to testing.
What I just did was: 
I created the testing database simply with a command like 

mysqldump -u user --password='xxx' -h localhost -d production_db | mysql -h 
localhost -u user --passwor='xxx' -Dtest_db

Again, I must subclassing DiscoverRunner to have a chance to succeed (need 
to by-pass db creation), and actually Django complains if I don't do that. 
So, I subclassed the DiscoverRunner like this

class SkipDBCreationDiscoverRunner(DiscoverRunner):
def setup_databases(self, **kwargs):
return

def teardown_databases(self, old_config, **kwargs):
pass

and enabled this new thing to run instead of the default in settings.py:

TEST_RUNNER="tests.nodb_runner.SkipDBCreationDiscoverRunner"

I created a "TEST" entry in the DATABASES dictionary with the proper db 
name:
DATABASES = {
'default': {
'ENGINE': 'mysql.connector.django',
'NAME': 'production_db',
'USER': 'user',
'PASSWORD': 'xxx',
'HOST': 'localhost',
'OPTIONS': {
'autocommit': True,
},
},

'TEST': {
'ENGINE': 'mysql.connector.django',
'NAME': 'test_db',
'USER': 'user',
'PASSWORD': 'xxx',
'HOST': 'localhost',
'OPTIONS': {
'autocommit': True,
},
},
}


BUT, Django is using the production database! I don't know what I'm 
missing. Probably something stupid...


> I'm having serious doubts on how friendly Django-1.7 is with respect to 
> > TDD... 
>
> That seems an unfair conclusion, since your problems here mostly arise 
> from using legacy tables un-managed by Django. That's not the typical 
> situation for a Django project, and it's naturally one that will require 
> some manual work on your part for the corresponding testing 

Re: Loading fixtures in Django 1.7

[Leonard Wayne]

Fred,

Got it!!  Thank you!!

- Leonard

On Sunday, November 9, 2014 5:46:30 PM UTC-5, Leonard Wayne wrote:
>
> I am in the process of upgrading from
> Django 1.6 to 1.7.
>
> I have three fixtures.  I am trying to figure
> out how I should load them.
>
> One fixture is `initial_data.json`, and I know
> that starting with Django 1.7 this special
> fixture no longer gets automatically loaded
> as it did when we used to run `syncdb` (i.e.,
> prior to deprecation in Django 1.7).
>
> So I know all three fixtures should be loaded
> the same way as each other, whatever way that
> may be.
>
> My main question is:
>
> Should I keep using `loaddata`, as in:
>
> python manage.py loaddata .json
>
> Reading the documentation I get the sense
> (though I am not sure) that now the preferred
> approach to load fixtures is to create a
> migration to perform the loading.  But I
> don't see an example of how to do this
> process from beginning to end.  It looks
> like the process starts with creating an
> empty migration, then manually editing the
> migration file to define a function like:
>
> def load_data(apps, schema_editor):
>
> But I don't know how to write this function
> (`load_data`), and I can't find an example.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/dc8052d9-7be2-4a96-b9f0-8d4c0cd3f734%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 求解答 说是找不到'hello', 我看Python的搜索path 也对啊 附件是程序 我是第一次接触Django

[Ricardo L. Dani]

actually, or use 'mysite.viess.hello' on the second argument of your url
definition

2014-11-11 13:07 GMT-02:00 Ricardo L. Dani :

> missing
>
> from .views import hello
>
> on urls.py
>
> or use 'hello' as string
>
> 2014-11-11 11:54 GMT-02:00 tkdchen :
>
> 这不是Django的问题。你先把Python搞明白。
>>
>> On Sunday, November 9, 2014 11:29:58 PM UTC+8, zhoumin...@gmail.com
>> wrote:
>>
>>> NameError at /
>>>
>>> name 'hello' is not defined
>>>
>>>   Request Method: GET Request URL: http://127.0.0.1:8000/ Django
>>> Version: 1.7.1 Exception Type: NameError Exception Value:
>>>
>>> name 'hello' is not defined
>>>
>>>  Exception Location: E:\djcode\mysite\mysite\urls.py in , line 5 
>>> Python
>>> Executable: C:\Python27\python.exe Python Version: 2.7.6 Python Path:
>>>
>>> ['E:\\djcode\\mysite',
>>>  'C:\\Python27\\lib\\site-packages\\setuptools-1.1.4-py2.7.egg',
>>>  'C:\\Python27\\lib\\site-packages\\swampy-2.1.7-py2.7.egg',
>>>  'C:\\Python27\\lib\\site-packages\\django-1.7.1-py2.7.egg',
>>>  'C:\\windows\\system32\\python27.zip',
>>>  'C:\\Python27\\DLLs',
>>>  'C:\\Python27\\lib',
>>>  'C:\\Python27\\lib\\plat-win',
>>>  'C:\\Python27\\lib\\lib-tk',
>>>  'C:\\Python27',
>>>  'C:\\Python27\\lib\\site-packages']
>>>
>>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-users+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-users@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-users.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/8cf2f5d7-2906-4dad-88ab-0d6bd290008c%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> []`s
> Ricardo L. Dani
> http://about.me/ricardodani
>



-- 
[]`s
Ricardo L. Dani
http://about.me/ricardodani

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAEq3mei4Hd_t%3DZPaL23Q7yhQohPpm9VTAda5V8SPtrqyMZ-G6Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 求解答 说是找不到'hello', 我看Python的搜索path 也对啊 附件是程序 我是第一次接触Django

[Ricardo L. Dani]

missing

from .views import hello

on urls.py

or use 'hello' as string

2014-11-11 11:54 GMT-02:00 tkdchen :

> 这不是Django的问题。你先把Python搞明白。
>
> On Sunday, November 9, 2014 11:29:58 PM UTC+8, zhoumin...@gmail.com wrote:
>
>> NameError at /
>>
>> name 'hello' is not defined
>>
>>   Request Method: GET Request URL: http://127.0.0.1:8000/ Django Version:
>> 1.7.1 Exception Type: NameError Exception Value:
>>
>> name 'hello' is not defined
>>
>>  Exception Location: E:\djcode\mysite\mysite\urls.py in , line 5 
>> Python
>> Executable: C:\Python27\python.exe Python Version: 2.7.6 Python Path:
>>
>> ['E:\\djcode\\mysite',
>>  'C:\\Python27\\lib\\site-packages\\setuptools-1.1.4-py2.7.egg',
>>  'C:\\Python27\\lib\\site-packages\\swampy-2.1.7-py2.7.egg',
>>  'C:\\Python27\\lib\\site-packages\\django-1.7.1-py2.7.egg',
>>  'C:\\windows\\system32\\python27.zip',
>>  'C:\\Python27\\DLLs',
>>  'C:\\Python27\\lib',
>>  'C:\\Python27\\lib\\plat-win',
>>  'C:\\Python27\\lib\\lib-tk',
>>  'C:\\Python27',
>>  'C:\\Python27\\lib\\site-packages']
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/8cf2f5d7-2906-4dad-88ab-0d6bd290008c%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
[]`s
Ricardo L. Dani
http://about.me/ricardodani

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAEq3mejPbmcyXb5enbxOYBQNSSPt5HW9zMr_ZSkbQoV68WX%3DzA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Import Error Module

[Erik Cederstrand]

> Den 11/11/2014 kl. 15.48 skrev Niall :
> 
> Hello, I was hoping that anyone could please advise me on a very simple issue 
> which I am having regarding running the dev server (see attachments). I am 
> receiving the following import error when attempting to run.
> 
> ImportError: No module named django.core.management

Do you have django installed? Try running:

python -c "import django;"

If not, run "pip install django"

Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/2B51C236-77EA-4724-A4C2-8A34614C39C9%40cederstrand.dk.
For more options, visit https://groups.google.com/d/optout.

Re: how to test an application that's using a legacy database

[Carl Meyer]

Hi David,

On 11/11/2014 07:01 AM, dpalao.pyt...@gmail.com wrote:
> I see your point. You might be right, but it is not clear to me how to
> do it and if it would work: I have already tried to subclass
> DiscoverRunner to modify its behaviour with little success.

If there are specific aspects of "how to do it" that are confusing to
you, I could try to clarify. Or if you try it and have specific problems.

> Another problem that I see: it is not an homogenous approach. I mean,
> the models are created from the production database. Now I create an
> independent database for testing. Of course, you will tell me that I
> have to follow the TDD approach to the end: for the code that creates
> the testing database too! And I would agree. But it is clearly a bit too
> complicated.

I'm afraid I am quite confused by this paragraph.

I don't know what you mean by "not an homogenous approach".

And I don't know what you mean by "the models are created from the
production database."

And I don't know what you mean by "an independent database for testing."
Django already creates a new database for each test run. I'm not
suggesting creating any additional database beyond that, just running
some SQL to create your legacy (un-managed) tables in the testing database.

The code that creates the testing database will be exercised at the
start of every test run, and if it's not working your tests will fail
because the legacy tables are not created. Personally, I'd consider that
adequate; I wouldn't write any additional tests for that code.

> I'm having serious doubts on how friendly Django-1.7 is with respect to
> TDD...

That seems an unfair conclusion, since your problems here mostly arise
from using legacy tables un-managed by Django. That's not the typical
situation for a Django project, and it's naturally one that will require
some manual work on your part for the corresponding testing setup.

Carl



signature.asc
Description: OpenPGP digital signature

Re: how to test an application that's using a legacy database

[dpalao . python]

Dear Carl,
I see your point. You might be right, but it is not clear to me how to do 
it and if it would work: I have already tried to subclass DiscoverRunner to 
modify its behaviour with little success.
Another problem that I see: it is not an homogenous approach. I mean, the 
models are created from the production database. Now I create an 
independent database for testing. Of course, you will tell me that I have 
to follow the TDD approach to the end: for the code that creates the 
testing database too! And I would agree. But it is clearly a bit too 
complicated.
I'm having serious doubts on how friendly Django-1.7 is with respect to 
TDD...

Best,

David

On Monday, November 10, 2014 6:58:40 PM UTC+1, Carl Meyer wrote:
>
> Hi David, 
>
> On 11/10/2014 08:14 AM, dpalao...@gmail.com  wrote: 
> > Probably I was not clear in my original post. My problem is precisely 
> > how to switch managed to True just before the tests and put it back to 
> > False afterwards to avoid creating of tables by hand during the tests. 
> > That is precisely the trick described in the link I included in my first 
> > post: subclass the DiscoverRunner class. But I don't know how to achieve 
> it. 
>
> Fred posted about how to trick the ORM into creating these tables for 
> you. For what it's worth, if I were in this situation I would not try to 
> flip `managed` to `True` during testing for these tables. In production 
> these tables have a fixed known schema, they are not created by the 
> Django ORM. I'd prefer to replicate that situation in testing as well, 
> so that my tests would catch a mis-match between my ORM models for the 
> legacy tables and the actual schema of the tables. 
>
> So the approach I'd take instead would be to bypass the ORM entirely 
> when creating these tables. Instead create a SQL file with the DDL for 
> the exact schema of the real legacy tables, and then hook into the test 
> runner to run that SQL file directly against your test database. 
> Specifically, I think in a subclass of DiscoverRunner you could override 
> the `setup_databases` method and run your SQL immediately after that. 
>
> (Note that I haven't actually done this, so there may be caveats I 
> haven't anticipated. If you want a battle-tested solution, you might 
> prefer Fred's. But if I was in your situation, I would first try to get 
> a solution working that doesn't have the ORM create these tables for 
> testing.) 
>
> Carl 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/34abd904-c6e8-4878-98eb-fb25f70232f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 求解答 说是找不到'hello', 我看Python的搜索path 也对啊 附件是程序 我是第一次接触Django

[tkdchen]

这不是Django的问题。你先把Python搞明白。

On Sunday, November 9, 2014 11:29:58 PM UTC+8, zhoumin...@gmail.com wrote:
>
> NameError at /
>
> name 'hello' is not defined
>
>   Request Method: GET Request URL: http://127.0.0.1:8000/ Django Version: 
> 1.7.1 Exception Type: NameError Exception Value: 
>
> name 'hello' is not defined
>
>  Exception Location: E:\djcode\mysite\mysite\urls.py in , line 5 
> Python 
> Executable: C:\Python27\python.exe Python Version: 2.7.6 Python Path: 
>
> ['E:\\djcode\\mysite',
>  'C:\\Python27\\lib\\site-packages\\setuptools-1.1.4-py2.7.egg',
>  'C:\\Python27\\lib\\site-packages\\swampy-2.1.7-py2.7.egg',
>  'C:\\Python27\\lib\\site-packages\\django-1.7.1-py2.7.egg',
>  'C:\\windows\\system32\\python27.zip',
>  'C:\\Python27\\DLLs',
>  'C:\\Python27\\lib',
>  'C:\\Python27\\lib\\plat-win',
>  'C:\\Python27\\lib\\lib-tk',
>  'C:\\Python27',
>  'C:\\Python27\\lib\\site-packages']
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/8cf2f5d7-2906-4dad-88ab-0d6bd290008c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 求解答 说是找不到'hello', 我看Python的搜索path 也对啊 附件是程序 我是第一次接触Django

[tkdchen]

这不是Django的问题，你先把Python搞明白。

On Sunday, November 9, 2014 11:29:58 PM UTC+8, zhoumin...@gmail.com wrote:
>
> NameError at /
>
> name 'hello' is not defined
>
>   Request Method: GET Request URL: http://127.0.0.1:8000/ Django Version: 
> 1.7.1 Exception Type: NameError Exception Value: 
>
> name 'hello' is not defined
>
>  Exception Location: E:\djcode\mysite\mysite\urls.py in , line 5 
> Python 
> Executable: C:\Python27\python.exe Python Version: 2.7.6 Python Path: 
>
> ['E:\\djcode\\mysite',
>  'C:\\Python27\\lib\\site-packages\\setuptools-1.1.4-py2.7.egg',
>  'C:\\Python27\\lib\\site-packages\\swampy-2.1.7-py2.7.egg',
>  'C:\\Python27\\lib\\site-packages\\django-1.7.1-py2.7.egg',
>  'C:\\windows\\system32\\python27.zip',
>  'C:\\Python27\\DLLs',
>  'C:\\Python27\\lib',
>  'C:\\Python27\\lib\\plat-win',
>  'C:\\Python27\\lib\\lib-tk',
>  'C:\\Python27',
>  'C:\\Python27\\lib\\site-packages']
>
>
On Sunday, November 9, 2014 11:29:58 PM UTC+8, zhoumin...@gmail.com wrote:
>
> NameError at /
>
> name 'hello' is not defined
>
>   Request Method: GET Request URL: http://127.0.0.1:8000/ Django Version: 
> 1.7.1 Exception Type: NameError Exception Value: 
>
> name 'hello' is not defined
>
>  Exception Location: E:\djcode\mysite\mysite\urls.py in , line 5 
> Python 
> Executable: C:\Python27\python.exe Python Version: 2.7.6 Python Path: 
>
> ['E:\\djcode\\mysite',
>  'C:\\Python27\\lib\\site-packages\\setuptools-1.1.4-py2.7.egg',
>  'C:\\Python27\\lib\\site-packages\\swampy-2.1.7-py2.7.egg',
>  'C:\\Python27\\lib\\site-packages\\django-1.7.1-py2.7.egg',
>  'C:\\windows\\system32\\python27.zip',
>  'C:\\Python27\\DLLs',
>  'C:\\Python27\\lib',
>  'C:\\Python27\\lib\\plat-win',
>  'C:\\Python27\\lib\\lib-tk',
>  'C:\\Python27',
>  'C:\\Python27\\lib\\site-packages']
>
>
On Sunday, November 9, 2014 11:29:58 PM UTC+8, zhoumin...@gmail.com wrote:
>
> NameError at /
>
> name 'hello' is not defined
>
>   Request Method: GET Request URL: http://127.0.0.1:8000/ Django Version: 
> 1.7.1 Exception Type: NameError Exception Value: 
>
> name 'hello' is not defined
>
>  Exception Location: E:\djcode\mysite\mysite\urls.py in , line 5 
> Python 
> Executable: C:\Python27\python.exe Python Version: 2.7.6 Python Path: 
>
> ['E:\\djcode\\mysite',
>  'C:\\Python27\\lib\\site-packages\\setuptools-1.1.4-py2.7.egg',
>  'C:\\Python27\\lib\\site-packages\\swampy-2.1.7-py2.7.egg',
>  'C:\\Python27\\lib\\site-packages\\django-1.7.1-py2.7.egg',
>  'C:\\windows\\system32\\python27.zip',
>  'C:\\Python27\\DLLs',
>  'C:\\Python27\\lib',
>  'C:\\Python27\\lib\\plat-win',
>  'C:\\Python27\\lib\\lib-tk',
>  'C:\\Python27',
>  'C:\\Python27\\lib\\site-packages']
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/fd4ef940-77b1-4701-8044-ae85cc6b602d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: how to test an application that's using a legacy database

[dpalao . python]

Dear Fred,
Thanks a lot for the answer.
Actually I got very happy when I saw it. But I sadly found out that it does 
not work in my case. 

I think the problem is related to the way Django-1.7 behaves with respect 
to databases, migrations and so on. Not 100% sure, though.

I don't really know what to do...

Best


On Monday, November 10, 2014 4:18:27 PM UTC+1, Fred Stluka wrote:
>
> David,
>
> No.  You can use it unchanged.  With Django 1.4 at least, and I
> assume also with 1.7.
>
> I have a legacy MS SQL Server DB where I have rights to modify 
> data but not tables.  I also cannot create new DBs in MS SQL
> Server.
>
> I used *inspectdb* to create models from the existing DB.
>
> I generally have them marked as *managed=False*, but when 
> running tests, I have them *managed=True*, and I override the 
> *DATABASES* settings to point to SQLite, instead of MS SQL Server.
> Thus, when I run the tests, the test DB is created in SQLite, and
> the real DB server is untouched.
>
> Here's how I do it:
>
> *settings.py:*
>
> DATABASES = { ... the usual stuff ... }
>
> # Decide whether we're running unit tests
> RUNNING_UNIT_TESTS = 'test' in sys.argv
>
> if RUNNING_UNIT_TESTS:
> DATABASES['default'] = { 'ENGINE': 'django.db.backends.sqlite3', }
>
> *models.py:*
>
> class Meta:
> managed = True if settings.RUNNING_UNIT_TESTS else False
>
> --Fred 
> --
> Fred Stluka -- mailt...@bristle.com  -- 
> http://bristle.com/~fred/ 
> Bristle Software, Inc -- http://bristle.com -- Glad to be of service! 
> Open Source: Without walls and fences, we need no Windows or Gates. 
> --
>  On 11/10/14 9:43 AM, dpalao...@gmail.com  wrote:
>  
> Hi,
> I'm writing a Django application that uses an existing database. If I 
> understood it well, in such a case one must create non-managed models for 
> the legacy tables to avoid Django creating already existing tables, right?
> For instance, this is how one of my models looks like:
>
>  class JobInfo(models.Model):
> job_db_inx = models.IntegerField(primary_key=True)
> id_job = models.IntegerField()
> id_user = models.IntegerField()
> id_group = models.IntegerField()
> account = models.TextField(blank=True)
> cpus_req = models.IntegerField()
> cpus_alloc = models.IntegerField()
> nodelist = models.TextField()
> nodes_alloc = models.IntegerField()
> partition = models.TextField()
> time_start = models.IntegerField()
> time_end = models.IntegerField()
> was_updated = models.IntegerField()
> jobmondatacleared = models.IntegerField(db_column='jobMonDataCleared') 
>  # Field name made lowercase.
> endupcount = models.IntegerField(db_column='endUpCount')  # Field 
> name made lowercase.
> approved = models.IntegerField()
>
> class Meta:
> managed = False
> db_table = 'job_info'
>  
> The problem, of course happens when the unit tests are run. The test 
> database must be created when the tests start. But because "managed = 
> False", the tables are not created.
>
> First round.
> Googling a bit I found a recipe to by-pass this problem: modify the 
> DiscoverRunner class (I found it in here 
> ,
>  
> and tailor it trvially to remove the deprecation warning):
>
>  class ManagedModelDiscoverRunner(DiscoverRunner):
> def setup_test_environment(self, *args, **kwargs):
> from django.db.models.loading import get_models
> self.unmanaged_models = [m for m in get_models()
>  if not m._meta.managed]
> for m in self.unmanaged_models:
> m._meta.managed = True
> print("setting %s._meta.managed to True" % (m.__name__,))
> super(ManagedModelDiscoverRunner, self).setup_test_environment(*
> args, **kwargs)
>
> def teardown_test_environment(self, *args, **kwargs):
> super(ManagedModelDiscoverRunner, self).teardown_test_environment
> (*args, **kwargs)
> # reset unmanaged models
> for m in self.unmanaged_models:
> m._meta.managed = False
>
>  
> So I created a directory in my project called "tests" and put the above 
> code in a file called "managed_runner.py" in there. To be more explicit, 
> the tree looks like:
>
>  |-- myapp
> |   |-- admin.py
> |   |-- __init__.py
> |   |-- models.py
> |   |-- templates
> |   |   `-- myapp
> |   |   `-- home.html
> |   |-- tests.py
> |   `-- views.py
> |-- myproj
> |   |-- __init__.py
> |   |-- settings.py
> |   |-- urls.py
> |   `-- wsgi.py
> |-- manage.py
> `-- tests
> |-- __init__.py
> `-- managed_runner.py
>
>  
> Then I modified my "settings.py" file adding 
>
>  TEST_RUNNER="tests.managed_runner.ManagedModelDiscoverRunner"
>  
> to it. And I ran the tests. Still, it fails:
>
>  django.db.utils.ProgrammingError: Table 'test_db.job_info' doesn't exist
>  
> But I see 

Re: Django MPTT Admin

[Neeraj Sharma]

Thanx for your quick response Matthias Kestenholz, but i actually i want to 
use MPTT Admin as an inline form, code you have written will work as a 
normal admin form

On Thursday, 26 February 2009 15:12:15 UTC+5:30, Matthias Kestenholz wrote:
>
> Hey,
>
> A topic which comes up on this list from time to time is an automatic
> admin interface for django-mptt. I'd like to advertise a piece of code
> we have written at our company a little bit, and I'd also like to invite
> everyone to give comments and feedbacks. I do have many more ideas
> floating around, and there are a couple of issues still open, but I think
> the code is ready for wider review and maybe usage, who knows?
>
>
> The current version of the code generates an interface with drag/drop
> capabilities for managing mptt-based trees. It's still very clear that the
> code was extracted from a `classical' page cms. All you need to do
> is the following:
>
>
> -- 8< --
>
> from django.db import models
>
> class Category(models.Model):
> title = models.CharField(max_length=200)
> parent = models.ForeignKey('self', related_name='children',
> blank=True, null=True)
>
> -- 8< --
>
> from django.contrib import admin
> from feincms.admin import editor
>
> class CategoryAdmin(editor.TreeEditorMixin, admin.ModelAdmin):
> pass
>
> admin.site.register(Category, CategoryAdmin)
>
> -- 8< --
>
> The generated admin interface looks like that:
>
> http://spinlock.ch/pub/feincms/category_tree_admin.png
>
> The page cms feeling is still very much there, but we'll see.
>
> In any case, you'll find the code on github:
> http://github.com/matthiask/feincms/tree/master
>
>
> Thanks,
> Matthias
>
>
> -- 
> "Programming is an art form, like the creation
> of poetry or music." (Donald E. Knuth, 1974)
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5031d94b-aa72-4607-b53c-b4818e7bd6fc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django MPTT Admin

[Neeraj Sharma]

Thanx for your quick response Matthias Kestenholz, but i actually i want to 
use MPTT Admin as an inline form, code you have written will work as a 
normal admin.

On Thursday, 26 February 2009 15:12:15 UTC+5:30, Matthias Kestenholz wrote:
>
> Hey,
>
> A topic which comes up on this list from time to time is an automatic
> admin interface for django-mptt. I'd like to advertise a piece of code
> we have written at our company a little bit, and I'd also like to invite
> everyone to give comments and feedbacks. I do have many more ideas
> floating around, and there are a couple of issues still open, but I think
> the code is ready for wider review and maybe usage, who knows?
>
>
> The current version of the code generates an interface with drag/drop
> capabilities for managing mptt-based trees. It's still very clear that the
> code was extracted from a `classical' page cms. All you need to do
> is the following:
>
>
> -- 8< --
>
> from django.db import models
>
> class Category(models.Model):
> title = models.CharField(max_length=200)
> parent = models.ForeignKey('self', related_name='children',
> blank=True, null=True)
>
> -- 8< --
>
> from django.contrib import admin
> from feincms.admin import editor
>
> class CategoryAdmin(editor.TreeEditorMixin, admin.ModelAdmin):
> pass
>
> admin.site.register(Category, CategoryAdmin)
>
> -- 8< --
>
> The generated admin interface looks like that:
>
> http://spinlock.ch/pub/feincms/category_tree_admin.png
>
> The page cms feeling is still very much there, but we'll see.
>
> In any case, you'll find the code on github:
> http://github.com/matthiask/feincms/tree/master
>
>
> Thanks,
> Matthias
>
>
> -- 
> "Programming is an art form, like the creation
> of poetry or music." (Donald E. Knuth, 1974)
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/83c717f4-12a6-4d01-88e6-0e8a4a0d9425%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django MPTT Admin

[Neeraj Sharma]

*How to use Django Mttp Admin as an Inline in admin.py* *?*

On Thursday, 26 February 2009 15:12:15 UTC+5:30, Matthias Kestenholz wrote:
>
> Hey,
>
> A topic which comes up on this list from time to time is an automatic
> admin interface for django-mptt. I'd like to advertise a piece of code
> we have written at our company a little bit, and I'd also like to invite
> everyone to give comments and feedbacks. I do have many more ideas
> floating around, and there are a couple of issues still open, but I think
> the code is ready for wider review and maybe usage, who knows?
>
>
> The current version of the code generates an interface with drag/drop
> capabilities for managing mptt-based trees. It's still very clear that the
> code was extracted from a `classical' page cms. All you need to do
> is the following:
>
>
> -- 8< --
>
> from django.db import models
>
> class Category(models.Model):
> title = models.CharField(max_length=200)
> parent = models.ForeignKey('self', related_name='children',
> blank=True, null=True)
>
> -- 8< --
>
> from django.contrib import admin
> from feincms.admin import editor
>
> class CategoryAdmin(editor.TreeEditorMixin, admin.ModelAdmin):
> pass
>
> admin.site.register(Category, CategoryAdmin)
>
> -- 8< --
>
> The generated admin interface looks like that:
>
> http://spinlock.ch/pub/feincms/category_tree_admin.png
>
> The page cms feeling is still very much there, but we'll see.
>
> In any case, you'll find the code on github:
> http://github.com/matthiask/feincms/tree/master
>
>
> Thanks,
> Matthias
>
>
> -- 
> "Programming is an art form, like the creation
> of poetry or music." (Donald E. Knuth, 1974)
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/8598b799-6371-4346-abd2-39c7726189a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.