Re: Reverse error in contrib.comments
On Wed, Oct 22, 2008 at 12:30 PM, Brandon Taylor
<[EMAIL PROTECTED]> wrote:
>
> The error is:
> Reverse for '' with arguments '()'
> and keyword arguments '{}' not found.
...
> I see there is an closed ticket: http://code.djangoproject.com/ticket/8571.
> I have cleared out all of my .pyc files as suggested, but I'm still
> getting the template error. Can anyone offer any advice?
Are you using v1.0, or are you using a post v1.0 checkout (either from
trunk or from the v1.0.X branch)? The ticket you have referenced was
closed because it appeared to be a duplicate of #9038; that ticket was
fixed after the release of v1.0, which means that the v1.0 release
doesn't contain the fix. If you can update to a recent checkout, you
should be able to resolve the problem.
If you're using a recent (i.e., post [9087]) checkout, you may have
found a new bug, in which case, having some additional debug
information (such as a minimal test project that demonstrates the
problem) would be helpful.
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Mercurial or Git
On Thu, Oct 23, 2008 at 3:54 AM, Rit Lim <[EMAIL PROTECTED]> wrote: > > which one is the Django community moving toward to, mercurial or git? > if Django is to be moved... Several of the core developers are already using distributed version control systems to manage their activities. Git, for example, has very good SVN integration, and it is possible to work on a daily basis with a Git repository but make public commits to an SVN repository. I believe Mercurial has similar tools. However, there are no plans in place to migrate the official Django repository to any distributed version control system. The very nature of an 'official' repository dictates that there must be a single canonical checkout; SVN already provides this facility. The very fact that you are have to ask "which DVCS system should I use" also points to a problem - without a clear winner, any decision will inevitably shut out a portion of the community. For all its problems, SVN remains a reliable lingua franca. Please note: This is not an invitation to try and convince the core developers to change our mind. The core developers are well aware of the benefits and limitations of distributed version control, we have considered the options, we have made our decision for the moment, and we're not looking for community feedback on the decision. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Ordering M2M field?
On Fri, Oct 24, 2008 at 10:16 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > OK, I have a model with a many to many relationship.. pretty > straightforward pre-1.0 code: > > class SpecialEvent(models.Model): >sponsors = models.ManyToManyField(Advertiser, related_name="event > sponsors", null=True, blank=True) > > Problem is, the Powers That Be want those sponsors in a certain order. > I thought they just showed up in the order in which they were added in > the admin (ordered by id on their table) > > That does not appear to be the case. They appear to order themselves > based on their own id. > > So, how can I set the order in which they appear? If you want reliable ordering, then you have to have something reliable to order by. If you want reliable ordering of an m2m relation, you will need to use a m2m-intermediate model for your m2m relation and put an extra field on the intermediate model that can be used as the basis for reliable ordering. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: database API from external tools?
On Sat, Oct 25, 2008 at 3:55 AM, Andrew Chapman <[EMAIL PROTECTED]> wrote: > > Hi everyone, > > Very much a Django newbie here, I'm trying to evaluate a few things > before diving right in. > > I was all set to write something in Ruby Rails, but the reason for > looking at Django is because I also need python access to all the same > data that the web app is dealing with. The Django database API seems > great, but I can only easily run it on the web app server. I'm not sure why you think this. The Django database API is just a bunch of Python modules. If you import those modules into your code, you can manipulate a database to your heart's content. There is no requirement that the python code be deployed on a web server. Django code is just Python code - a web server is just one way of executing Python code. > My question is how to package up and deploy the Django python code for > external tools to access the database? I'm hoping to have the Django app > sitting on the web server, with the source tree inaccessible to a bunch > of workstations. The workstations need some command line tools for > interacting with the database, and I don't want to have to bundle up the > whole app and duplicate it out on the workstations, just so they can > access the database API. > > If I can access the whole app source code I can set the > DJANGO_SETTINGS_MODULE env var and run python in a shell, and from there > import my app's python module, and it all seems to work pretty well, but > I'm looking for a more encapsulated/packaged way of deploying access to > the database API without the whole app tree. > > If anyone has any tips or online guides for this issue it would be much > appreciated. Well, I'm not sure exactly what you're looking for here. If you just want the Django database API, then put the Django code (i.e., django.*) on the workstations, and just write your tools to import that code, setting up DJANGO_SETTINGS_MODULE as required. If you also want your model definitions, then you're going to have to deploy those too. i.e., if you have an Author model, and you want that model to be usable in your tool suite, then you will need to provide the model definition. Again, there is no requirement that the model be deployed on a web server - I have any number of tools and data manipulation scripts that run from a cron job or from a shell prompt that access the Django models to simplify database access. Obviously, the easiest way to get all the required code is to do a full checkout of your web application on the workstation, but this isn't a requirement. Assuming there are no weird dependencies in your code, the model layer will work fine if the views are missing - strictly, the only part of your code that should need to exist on the workstation are the model definitions. Managing an extraction of a partial checkout of your project code is left as an exercise for the reader. Now, I'm guessing you've tried something like this, met with difficulty, and come to the conclusion that Django apps can only be deployed via a webserver. If you can describe exactly what you have done and the problems you have experienced, we can possibly provide some assistance. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: database API from external tools?
On Mon, Oct 27, 2008 at 6:05 AM, Andrew Chapman <[EMAIL PROTECTED]> wrote: > > Russell Keith-Magee wrote: >> On Sat, Oct 25, 2008 at 3:55 AM, Andrew Chapman <[EMAIL PROTECTED]> wrote: >> >>> My question is how to package up and deploy the Django python code for >>> external tools to access the database? I'm hoping to have the Django app >>> sitting on the web server, with the source tree inaccessible to a bunch >>> of workstations. ... >> If you just want the Django database API, then put the Django code >> (i.e., django.*) on the workstations, and just write your tools to >> import that code, setting up DJANGO_SETTINGS_MODULE as required. >> >> If you also want your model definitions, then you're going to have to >> deploy those too... >> ...the model layer will work fine if the views are missing - >> strictly, the only part of your code that should need to exist on the >> workstation are the model definitions. Managing an extraction of a >> partial checkout of your project code is left as an exercise for the >> reader... >> *Obviously, the easiest way to get all the required code is to do a >> full checkout of your web application on the workstation...* > > Ok, thanks. > I just wanted to confirm that duplicating the web app out to the > workstations just so they can access the database API was the expected > course of action in this scenario. > It feels dirty to me! No - that isn't what I said at all. What I said is that you will need _pieces_ of the web app - specifically the model definitions, plus the main configuration file. I expect that the model definitions will also have some dependencies, but I can't tell what those are without seeing your code. The _easiest_ way to know you have satisfied all internal dependencies is to copy the full web app. However, this is not the _only_ way, and if you're willing to handle the configuration management issues, you could provide a partial checkout and achieve the same outcome. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: How to run testcases of %Django_Home%/tests/* ?
On Thu, Oct 30, 2008 at 5:37 PM, GAEFans <[EMAIL PROTECTED]> wrote: > > How to run testcases of %Django_Home%/tests/* ? By following the instructions: http://docs.djangoproject.com/en/dev/internals/contributing/#running-the-unit-tests 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Query subset
On Fri, Oct 31, 2008 at 4:08 PM, Tonne <[EMAIL PROTECTED]> wrote: > > So, what I've done is use Model.objects.values() to limit the returned > values, which is not ideal as I'm losing the objectness of the > queryset. > > I've worked around the loss Queryset.get_absolute_url by using a less > than elegant semi-hardcoded url. > > So if I'm missing a blindingly obvious way of limiting a query to > nominated fields so that I can still keep the benefits of a queryset, > please let me know. Right at the moment, there is no easy way to retrieve a subset of the fields on a model _and_ retain the 'modelness' of the data. values() querysets returns dictionaries, normal querysets return model instances. It sounds like ticket #5420 [1] describes the feature you are looking for; there has been some work on this ticket, but it isn't available in the trunk yet. [1] http://code.djangoproject.com/ticket/5420 > Also, is using Model.objects.values() to limit the fields returned > actually more efficient than Model.objects.all() in terms of database > hits? As always, the answer is "it depends", but generally speaking, if you have a model with a lot of columns (especially a lot of large text columns), a values() queryset will be more efficient. The efficiency gains are due to the reduction in the amount of data that is being retrieved from the database, and the volume of data that is transmitted. If your database has to do less paging to return results, and the volume of data that is transmitted is lower, the results will be retrieved faster. However, if each database record fits on a single page, or the protocol overhead associated with returning a row is comparable in size to the row itself, the efficiency gains will be minimal. Also, the efficiency gains of using values() will be largely negated if you end up doing multiple values() calls to retrieve the rest of the data. If you're going to need all the data anyway, it may be faster to live with the initial performance hit. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Confused about unittests and fixtures
On Fri, Nov 7, 2008 at 1:00 AM, AndyH <[EMAIL PROTECTED]> wrote: > > Hello, > > I have the following simple test which demonstrates the confusing > behaviour I'm seeing: > > class AvailabilityTestCase(django.test.TestCase): >fixtures = FIXTURE_LIST >def setUp(self): >response = self.client.login(username='testuser', > password='password') >self.assertTrue(response) > >def test_page(self): >print Calendar.objects.all() >print Calendar.objects.all() > >def test_page_again(self): >print Calendar.objects.all() >print Calendar.objects.all() > > When I run this from "manage.py test", it prints out four lists of > Calendars as expected. However, the second two, are slightly different > to the first two. As far as I'm aware I'm not doing anything to the > all() method (or subscribing in to any triggers) that might cause > this. But even if I was, my understanding is that the fixtures are > refreshed for each test so they can run independently of each other. > In my case, which ever order I run these two tests the second set > always prints different results to the first. Assuming that FIXTURE_LIST is correctly defined and references well formed fixtures, I can't see anything obviously wrong with your example. You are correct in your understanding that a Django TestCase will flush the database at the start of each test, so both tests should have a clean database and be reporting the same results. The suggestion that the GenericForeignKey is the source of the problem is certainly plausible. I'm not aware of any problems serializing Generic FK's, but they are more complicated and less exercised than regular keys and fields, so it is certainly a reasonable place to start looking. If you could provide a minimal complete example of this behaviour and attach it to a new ticket, it would be most helpful. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Confused about unittests and fixtures
On Fri, Nov 7, 2008 at 8:17 AM, Alex Koshelev <[EMAIL PROTECTED]> wrote: > GenericForeignKey and content type application itself look very doubtful for > me. If you have a ForeignKey to the ContentType model then you depends on > order with ContentType objects creates on syncdb. Because ContentType that > references to some model can have different primary key any time you flush > database. "Doubtful" is a little harsh. Contenttypes and GenericForeignKeys both work fine, and there are extensive unit tests to demonstrate this. They also work fine in the presence of fixtures, given certain preconditions. You are correct in saying that fixtures with ContentTypes can have problems - these are well understood, and I have plans to address the problems as part of a fix for ticket #7052. However, as long as your test data is self contained - i.e., you're not relying on the implicitly created ContentTypes - you should be fine. However, this point is worth clarifying for Andy's benefit. Andy: Does your test fixture contain the content type definitions? Since ContentType is a dependency of your Calendar app (by virtue of the Generic Key), the content types will need to be in the fixture. Is this the case with your project? 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Fixtures erase data?
On Sat, Nov 8, 2008 at 5:13 AM, Dana <[EMAIL PROTECTED]> wrote: > > Hey everyone, > > I just set up a few fixtures for some of my models and realized that > every time I syncdb it changes the existing data in my database. I > assume this is normal behavior, but I was wondering if it is possible > to have the fixtures only *add* data and not change it? The initial data fixture is reloaded every time that syncdb is executed; this will overwrite any changes that have been made to that initial data. This is normal, intended behaviour, and there isn't a setting or option to change this behaviour. Having an option to add data in the way you describe isn't really a good idea. If the syncdb behaviour was changed to add rather than overwrite initial data, you would have a different (and IMHO much worse) consequence - each time you run syncdb, you will end up with another copy of the initial data. If you run syncdb 100 times, you would end up with 100 copies of each fixture object. The purpose behind the initial data fixture is to provide *absolutely essential* initial data that must exist in order for the database to work - for example, the root node of a tree structure. If you have other data that is required to bootstrap the system - especially if that data is subject to change over the lifespan of the website - define that data in a fixture other that initial_data (say bootstrap_data), and manually load that fixture using loaddata. That way the bootstrap data will only be loaded (and therefore overwritten) when you explictly request a reload. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Easy way to serialize objects
On Sat, Nov 8, 2008 at 1:35 AM, Ivan Tarradellas <[EMAIL PROTECTED]> wrote: > > Hi all, > > With Django, what is the easy and best way to serialize/deserialize > objects that are no Django objects? > > django.core.serializers only works with Django objects. But what > happens if we have other object type? The short answer is "you have to build the serializer yourself". Django doesn't provide any mechanism for serializing arbitrary Python objects. The long answer depends on the serializer you want to use. Django's model serialization module builds on a number of other libraries (Python's builtin XML handling, simpleJSON, YAML, etc). These libraries handle the logic for how to serialize python primitive types (integer, list, etc). The Django serialization module describes how to decompose a django model instance into a series of primitives. If you want to serialize your own arbitrary object, you will need to come up with a similar set of rules, and wrap it around the base serialization libraries. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Fixtures erase data?
On Sat, Nov 8, 2008 at 1:19 PM, Dana Woodman <[EMAIL PROTECTED]> wrote: > >> Having an option to add data in the way you describe isn't really a >> good idea. If the syncdb behaviour was changed to add rather than >> overwrite initial data, you would have a different (and IMHO much >> worse) consequence - each time you run syncdb, you will end up with >> another copy of the initial data. If you run syncdb 100 times, you >> would end up with 100 copies of each fixture object. > > What I was envisioning was a solution that would check if the PK existed, if > it did, it would pass, if not, it would add the rows. The intended use was > to populate a database at first go with the needed data, but still be able > to run syncdb without mucking things up. Guess I'll have to go the other > route. This idea is a little more sound, and is certainly in the realm of the possible. I have some plans to improve fixture loading as a part of my work on ticket #7052; Adding a --noclobber option would be a reasonable extension to this work. I would suggest opening a ticket so that the idea isn't forgotten. If you want to work on a patch, that would be even better. >> The purpose behind the initial data fixture is to provide *absolutely >> essential* initial data that must exist in order for the database to >> work - for example, the root node of a tree structure. If you have >> other data that is required to bootstrap the system - especially if >> that data is subject to change over the lifespan of the website - >> define that data in a fixture other that initial_data (say >> bootstrap_data), and manually load that fixture using loaddata. That >> way the bootstrap data will only be loaded (and therefore overwritten) >> when you explictly request a reload. > > Thanks, that is good advice, I will go ahead and do that. That will > accomplish just about what I am looking for. > > Would it suffice to just rename the file/folder to > bootstrap_data/bootstrap_data.json? Does Django look for a file called > initial_data.json in a folder called initial_data, or does it just look for > any file called initial_data.json? Django looks for a file called initial_data.* in each of the /fixture directories, plus each of the directories mentioned in settings.FIXTURE_DIRS, plus the current working directory. The same rules apply for any other fixture name. So - if you can currently load initial_data.json, renaming it bootstrap.json is all you need to do. Django's fixture loader doesn't use directory names as part of the lookup scheme unless explicitly instructed to do so as part of the settings.FIXTURE_DIRS option. Unless you particularly want to have your fixtures in separate directories, there is no need to move initial_data into a different directory. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: loading initial data with yml
On Mon, Nov 10, 2008 at 6:30 PM, Adda Badda <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> Im having a problem loading initial data into my app with yaml. I have
> installed yaml for python using macports and placed the package in my
> site-packages directory. From the shell the yaml package loads when I
> type "import yaml" but django still tells me: "yml is not a known
> serialization" when I try and load data.
yml isn't a known serialization format, but yaml is. Django uses file
extensions to identify file types; you need to name your fixtures
my_fixture.yaml, not my_fixture.yml.
If you specifically want to use yml as an extension for fixtures, you
will need to register the YAML serializer with that extension. This
can be done by putting the following into your settings.py file:
SERIALIZATION_MODULES = {
'yml': "django.core.serializers.pyyaml"
}
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: How can I create a new table without primary key filed?
On Mon, Nov 10, 2008 at 7:59 PM, K*K <[EMAIL PROTECTED]> wrote: > > Hi, all. > > How can I create a new table without primary key in Django modeling. ? > > I'm porting a old program to Django web framework. After inspect > database to modules.py and then syncdb, It create the id filed with > primary key attribute, how can I disable this feature ? inspectdb isn't perfect - it's just a starting point that will hopefully remove the need to do a lot of typing. It is entirely expected that you will need to tweak the model provided by inspectdb. If inspectdb is producing an extra 'id' field in the model it suggests, just delete that field from the suggested model. However, because of the way Django operates, you will need to nominate one of the fields in your model to be the primary key. In your case, I'm guessing that inspectdb can't find an obvious candidate for the primary key, so it has given up and put an extra 'id' field into the definition it suggests. You can choose any field you want to be the primary key (provided it actually contains unique data). It doesn't matter what that field is called - it just needs to set the primary_key attribute to True. For example, if one of your models has a 'name' field that could be used as a primary key, you would use a definition something like: name = models.CharField(max_length=40, primary_key=True) 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django Forums
On Thu, Nov 13, 2008 at 3:37 AM, IMTheNachoMan <[EMAIL PROTECTED]> wrote: > > I realize that Django uses google groups for discussions and what not > but I was wondering how people felt about a Forum? Something with a > little better UI and better organization. Search the archives. This has come up many, many times before, and has been rejected every time. If you feel like you need a better UI, then you probably need to look into getting a better mail client. I certainly contest the assertion that forums have a better UI than a mailing list. Quite frankly, I haven't come across a single online forum that doesn't make my eyeballs itch. Completely aside from any UI issues, mailing lists also have the significant benefit that you can download all the content onto your local machine, so if you're on a plane or otherwise disconnected from the intertubes, you still have access to your mail. A couple of people have tried setting up forums. However, I can't remember the name or URL of a single one of them. I certainly don't post to any of them. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django newbie observation
On Thu, Nov 13, 2008 at 4:12 AM, ayayalar <[EMAIL PROTECTED]> wrote: > > I know Django is new and improving. I just wanted to point out these > issues a newbie is might be facing. Thanks for taking the time to give us this feedback. However, I would point out that while you have told us what is wrong with Django, you haven't really told us how you think we could fix those problems - or more importantly, how *you* would like to help us fix these problems. This is a volunteer project - nobody is paid to work on Django, so the only way that things get better is if people volunteer their time. "But I'm just a noob!" you cry. That's no excuse - the experience of newcomers is the best kind of help for the tutorial process. You are the person who has no preconceived ideas about what can or can't be don't, or how anything should be done, or where the answer to any given question should be found. While you're coming up to speed with Django, take notes. Turn those notes into suggestions, and then turn those suggestions into patches for documentation. If you think we need a new tutorial - write one. If you think the documentation requires elaboration for one particular feature - write it. If you think that there is some navigational issue with the existing documentation - make a suggestion. We're not operating under the illusion that Django is perfect. We're always open to suggestions on how to make things better. We're even more open to suggestions that are backed up with action. However, nothing gets better unless someone pitches in to help. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Testing system and alternate template languages
On Thu, Nov 13, 2008 at 9:58 AM, Erik <[EMAIL PROTECTED]> wrote: > > I am involved in a project that's using django with the mako_django > package for template rendering. I'm working on the unit tests, but > I'm running into the problem that the context and template are not > returned after a query from the test client (the members in the > response are empty). I'm assuming that the reason for this is that > I'm using a non standard template system, and I was wondering if there > is a good way to add the full testing support to another template > language. > > Can anyone give me some advice about how to get the test framework > working with an alternate template system? The Django test client logs templates and contexts by adding signal handlers during the setup phase of the test process. This setup phase instruments the Django template language so that whenever a template is rendered, a signal is fired; the test client listens for that signal, and the the template and context detail is saved for later use. If you are using a different template language, you will need to provide similar instrumentation. As long as your template language uses the a "template + context" approach to rendering, you should be able to use the same signal. The instrumentation is defined in django/test/utils.py. instrumented_test_render() is the instrumented rendering mechanism; it is installed using setup_test_environment(), and removed again using teardown_test_environment(); these methods are invoked as part of the Django test runner. If you write your own setup/teardown, you can install your own instrumentation; you then need to define a custom test runner that will invoke your own setup and teardown scheme. This process of integrating custom setup/teardown processes is certainly something that could be optimized; I'm open to any suggestions as to how it could be improved (I have a few ideas, but I'd like to hear opinions from a fresh mind before I introduce them). 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django Forums
On Thu, Nov 13, 2008 at 10:13 AM, joshuajenkins <[EMAIL PROTECTED]> wrote: > > Personally, I detest the mail list format. There are forums out there > that aren't all about signatures and annoying avatars, Vanilla is > something that comes to mind. It's all about the presentation. I can't do anything about personal taste, and I like vanilla (in code, in discussion fora, and in ice cream). > Anyway, my point being that the lack of a familiar forum-type > environment to post questions is a deterrent to adoption. I challenge you to back up that assertion. As I write this, there are 11825 members on the Django-users mailing list. We average 2500 or more posts per month, and that number has been steadily growing for 3 years. If you're going to throw around accusations that the mailing list serves as a barrier to adoption, you'd better come armed with some compelling statistics. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Book or documentation first
On Fri, Nov 14, 2008 at 7:18 AM, waltbrad <[EMAIL PROTECTED]> wrote: > > Which is best to read the Django book, or to read the documentation/ > tutorial? > > I know someone is likely to say both, but which is best to read > first? Will one get you and going faster than the other? At this point, the documentation and tutorial is a better bet for a newcomer. The book is very good, but unfortunately there have been a lot of changes to Django since it was written. There is still a lot of good material in there, but a newcomer won't know which bits are still current and which bits have been deprecated, so they would probably be better served by documentation that is known to describe the current state of play. The tutorial and online docs are part of Django itself, and have been kept up to date, so they are less likely to cause confusion. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Testing system and alternate template languages
On Fri, Nov 14, 2008 at 12:13 PM, Erik <[EMAIL PROTECTED]> wrote: > > In case there are others following this topic, I have the test system > working. I ended up putting a couple of functions in the contrib > folder of my django installation under the mako_django folder. The > functions emulate the behavior of the instrumented_test_render and > run_tests functions from django.test.utils an django.test.simple > respectively. This is pretty much the simplest scheme I could come up > with, and I'm sure a different implementation would provide more > features. However, it does allow you to access the template and > context members of the result when using the django test client. > Russ -- Thanks for your help. After browsing around in the code, I > think the process for adding at least this much test functionality for > an external template system was relatively painless. I would welcome > any comments (or corrections) regarding this solution if you have > them. As far as improvements, I think all that's really needed is a > little howto (to which I would be happy to contribute). It seemed > easy enough at least in this case that adding special support might be > overkill. Documentation improvements are always welcome. > If anyone wants to try it, what I did was to put the following code in > django/contrib/mako_django/__init__.py: Thanks for taking the time to do this Erik. One minor suggestion - there's not really any need to put this into the django.contrib namespace. django.contrib is intended as a collection of officially sanctioned extensions, not a general storage place for other plugins. It shouldn't make any difference to the way your code runs - it just means people don't get confused into thinking that your code is part of the official distribution that they are missing for some reason. Another suggestion, but a procedural one: I would suggest that you upload this to djangosnippets.org. As a message in a mailing list, this good work is easy to lose - on snippets, it is archived along with lots of other useful goodies. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Web 2.0 app in django - the admin does everything I need (It seems)
On Sat, Nov 22, 2008 at 10:27 PM, dash86no <[EMAIL PROTECTED]> wrote: > > So my question is, can I expect building forms using the templates/ > views to be as simple as getting things up in the admin. Will using views, forms and templates be as simple as configuring the built-in admin site - of course not. If you're getting into views, forms and templates, you're going to need to understand how to write Python, HTML, Javascript and CSS, and understand how HTTP constrains the way you can interact with your user. Theres a lot more to it than just configuring some convenient, precanned layout options. However, there is a lot of things that you can do with your own views, forms and templates that would be difficult to achieve within the constraints of the admin app. Hand-writing views, forms and templates will be more complex, but will ultimately be more flexible. > Is there > really much advantage to moving beyond the admin in my case? You haven't given us anywhere near enough detail to be able to answer this question. The builtin admin application is very rich, but it does have limitations; whether those limitations are important to you depends on your specific requirements. I've used SugarCRM, and there is a lot that Sugar does (especially in terms of workflow) that the builtin Django admin doesn't do. If you're just looking for a neat data entry and retrieval platform, you may not need anything more than the Django admin. If you only want to add a few minor custom views, you may be able to get away with some simple customization to the admin application. If you want custom workflows, etc, it will probably be easier to build them yourself rather than try to duct tape them to the side of the admin app. > Is there > any example of people using the admin to build web 2.0 like apps? This depends entirely upon what you take Web 2.0 to mean. It's a hideously vague phrase - depending on the speaker, it could refer to: a) The use of interactive AJAX widgets b) Exposing APIs to enable mashups c) The social nature of the experience of using the website d) The ability to generate venture capital funding through the sprinkling of magical web 2.0 fairy dust. If you just mean (a), then there are examples around that demonstrate how to install custom widgets, AJAX or otherwise, into the Django admin application (or any other Django form for that matter). Google is your friend. If you mean (b) or (c), you're definitely outside the realm of what Django's admin does out of the box. If you mean (d), I have a bridge to sell you. :-) > Or > is there a lot of functionality I'd be missing out on? The Django Admin application is very neat tool. It gives you an immediate interface with which you can start playing with data. However, it shouldn't be confused with a "finished Web 2.0 application". It is quite accurately described as an admin application - it exposes all your data to make it easy for an administrator or otherwise trusted individual to fiddle and tweak the internals of a database. Yes, it does have a lot of customization potential, but you shouldn't take that as an opportunity to confuse the admin application with a turnkey CMS platform (or a turnkey anything else for that matter). If your needs are relatively simple, and your users are trusted and don't require workflow constraints, the Django admin may meet your needs. However, I would suggest that for any non-trivial application you would be well served to look at stepping outside the constraints of the admin and into building a fully fledged website of your own. This may seem daunting, but keep this in mind: Django's admin application isn't magic. It isn't doing anything you can't do yourself in your own code. In fact, at one level, Django's admin is essentially just an advertisement for how easy it is to generate views of complex data in a completely generic fashion. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Weird error when doing loaddata
On Sun, Nov 23, 2008 at 8:09 AM, Erik Allik <[EMAIL PROTECTED]> wrote: > > I'm doing django-admin.py loaddata with a JSON file containing just > [], i.e. an empty fixture, to rule out any possibility of invalid data > being in the fixture, but still getting the following traceback: > > http://dpaste.com/92961/ > > The DB schema is in sync with the model definitions. The application > is running well in all other aspects. > > Any clues? Are you absolutely certain that the fixture that you think is being loaded is actually being loaded? The error you are reporting suggests that data is actually getting loaded, and that the data is not compatible with the schema. On top of that, if your fixture is empty, Django should be reporting an error - a fixture that adds no objects is considered to be an error, and will be reported as such. Check the error message very carefully - in particular, the exact path to the fixture being loaded. If the fixture at that location actually is empty, you may have found a bug, and we'll have to dig a little deeper. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Weird error when doing loaddata
On Sun, Nov 23, 2008 at 10:07 AM, Erik Allik <[EMAIL PROTECTED]> wrote: > > Thanks, your suggestion to very carefully check the fixture path led > me to realizing the problem. I wanted to load the service.json file > located in the working directory but loaddata was actually using the > one in the fixtures subdirectory which was completely outdated. > > Nevertheless, I think Django should throw a warning in cases like > this, or even prefer the fixture located in the working directory > instead. I know the current behavior is documented but it doesn't mean > it's intuitive. I'm not sure I follow. The arguments to loaddata are fixture names, not filenames. The current working directory is just one of the locations that Django looks for fixtures. If Django finds multiple fixtures matching the name provided, all the fixtures are loaded. This is well documented, and established behaviour - changing at this point would be a big backwards incompatibility. In your case, you have been bitten by a bad fixture in an unexpected location, but the error message pointed you explicitly at the fixture causing a problem. If that fixture didn't have an error in it, it would have been loaded, and loaddata would have reported 'X fixtures loaded from 2 files' - again, the message gives you enough detail to identify the problem. What warning messages you expect to see, and under what conditions? 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: debug view and list of GET or POST parameters
On Tue, Nov 25, 2008 at 7:21 PM, Thomas Guettler <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> If GET or POST contain a list, I only see the last value in the debug view.
>
> What do you see on an uncaught excepion with e.g. "?foo=1&foo=2" as
> query string?
It depends on how you try to access the values. request.GET and
request.POST aren't normal dictionaries - they are QueryDicts. As you
have noticed, if you use normal array subscription (i.e.,
request.GET['foo'] ), you will retrieve the last value that was
submitted. However, if you ask for request.GET.getlist('foo'), you
will get the list of all values that have been assigned to foo.
There are a number of other nifty tricks that you can do with
QueryDict; for more details, see the docs:
http://docs.djangoproject.com/en/dev/ref/request-response/#querydict-objects
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Best IDE for Django and python?
On Tue, Nov 25, 2008 at 5:42 PM, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: > > On Tuesday 25 November 2008 01:57:09 pm DragonSlayre wrote: >> How do you develop your django projects, and where do you go when you >> need to find documentation? > > why do you not check the archives of this list? You are the 10,000th person to > ask this same idiotic question Kenneth - that kind of attitiude doesn't help anyone, and doesn't make the Django community look good. Let's keep the personal epithets under control. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Best IDE for Django and python?
On Tue, Nov 25, 2008 at 5:27 PM, DragonSlayre <[EMAIL PROTECTED]> wrote: > > Hey, I'm getting started with a friend in developing a site with > Django, and we're both new to this, so I am wondering what people use > to manage all their files, and for looking at documentation etc. While I must apologize for Kenneth's poorly expressed frustration, his underlying message is sound - this has come up _many_ times on Django-users. A quick Google search should return many options, but there is no clear or correct answer to your question. > Having come from a Java background, I'm used to great documentation, > and suspect that Java is very much the leader in doc, and not the > standard. Having spent the afternoon wrestling with J2EE, I'd strongly disagree with this assertion. I will agree that Java projects tend to have have very extensive API documentation. This is a result of the combination of Javadoc and strong IDE integration that supports Javadoc. However, the quality of that documentation is highly variable. Unfortunately, the fact that Java IDEs automatically write Javadoc stubs and provide 1 button "build the documentation" hooks gives developers the mistaken impression that a project is "well documented". Documentation for the method "get_username()" that reads "Returns the username" doesn't really illuminate anything. There is also the argument that good APIs don't require lots of API documentation - after all, it should be obvious what get_username() returns. If your API entry points require extensive explanations, perhaps you need a better API. Good documentation means more than an API (and a _lot_ more than an empty autogenerated stub). Documentation means good explanations of the big picture - how the pieces fit together, how to achieve important tasks, significant internal states, etc. This sort of documentation doesn't fit well into simple API docs. It is also very hard to write, and as a result, it often isn't written, and when it is, it is rarely written well. This isn't unique to Java, either - the vast majority of open source projects suffer from this affliction. I'd like to think that Django is on the better end of the spectrum when it comes to documentation - we are blessed to have a journalism major amongst our project founders, and a couple of other liberal arts majors amongst the frequent contributors. As a result, docs.djangoproject.com is a pretty thorough resource, and is generally well written. This documentation is by no means perfect, but it is certainly better than a lot of other projects out there. In addition to the official documentation, there is a wealth of contributions on django-users and in the blogging community around Django that provides excellent material to supplement the official docs. Again, Google is your friend, and Django is a pretty specific Google keyword :-) > I've used the pydev plugin for eclipse, but it seems extremely > limited. I've used PyDev too, and I'd agree with your assessment. However, others seem to like it. YMMV. > How do you develop your django projects, and where do you go when you > need to find documentation? Your original query actually reveals a bias that is significant - why do you want an IDE in particular? Java, as a semi-traditional compiled language, lends itself to IDE development. The write-compile-run cycle places a certain imperative on getting code right the first time. Admittedly, the incremental compilation features of modern Java IDEs make this less of an issue, but the general language culture leans towards tools and development techniques that support this general philosophy. However, dynamic languages tend not to leverage IDEs as much. A lot of Python developers (and developers in other dynamic languages) tend to develop using relatively lightweight text editors. Some of these editors provide code highlighting, code completion, and other IDE-like features, but they definitely don't go as far as a traditional IDE. There are at least two reasons for this. Firstly, dynamic languages don't require a write-compile-run cycle, so they lend themselves to much greater experimentation. Want to know if an idea will work? Fire up an interactive Python shell and test out your idea. Editors can help you maintain scratchpads to develop a complex test harnesses; the Python runtime environment provides the ability to dynamically reload code modules during runtime. IDEs are very good when you're dealing with managing a body of code that is 'published' into a compiled product; I'm yet to see an IDE that can deal elegantly with the capabilities of a dynamic language. Secondly, there is the long standing "unix vs windows" philosophical argument. The Windows world (which, for all the Sun heritage, Java really is a part of) tends to push monolithic tools that do everything. The unix world, on the other hand, tends to push lots of little tools, each of which does one thing well. Want something to edit text? Get a good text editor. Wa
Re: Testing dynamic templates
On Tue, Nov 25, 2008 at 8:40 PM, Julien Phalip <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I've got a view which uses a different template depending on an input
> parameter. For example:
>
> def my_view(request, theme):
>...
>return render_to_response('my_app/%s/page.html' %s theme, {...})
>
> I would like to write some tests for this view, but I couldn't find
> any clean way to do so. So far, the only way I've found was to create
> a fake folder in the app's templates:
>
> my_app/
>templates/
>my_app/
>test_blah/
>page.html
>models.py
>tests.py
>views.py
>
> And then I can test the view by sending it the parameter 'test_blah'.
> It works fine, but it means I have to ship my app with that dirty
> "test_blah" folder.
>
> Is there any other way to proceed?
Check out django.contrib.auth.tests.views.py. The ChangePasswordTest
does some fancy footwork during the setUp and tearDown to install some
templates for testing purposes. You still need to ship the templates
as part of your project tarball, but they don't need to be in a
production-visible location - you can hide them away as part of the
testing infrastructure.
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Testing dynamic templates
On Tue, Nov 25, 2008 at 9:05 PM, Julien Phalip <[EMAIL PROTECTED]> wrote:
>
> On Nov 25, 11:01 pm, Julien Phalip <[EMAIL PROTECTED]> wrote:
>> On Nov 25, 10:56 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
>> wrote:
>>
>>
>>
>> > On Tue, 2008-11-25 at 20:47 +0900, Russell Keith-Magee wrote:
>> > > On Tue, Nov 25, 2008 at 8:40 PM, Julien Phalip <[EMAIL PROTECTED]> wrote:
>>
>> > > > Hi,
>>
>> > > > I've got a view which uses a different template depending on an input
>> > > > parameter. For example:
>>
>> > > > def my_view(request, theme):
>> > > >...
>> > > >return render_to_response('my_app/%s/page.html' %s theme, {...})
>>
>> > > > I would like to write some tests for this view, but I couldn't find
>> > > > any clean way to do so. So far, the only way I've found was to create
>> > > > a fake folder in the app's templates:
>>
>> > > > my_app/
>> > > >templates/
>> > > >my_app/
>> > > >test_blah/
>> > > >page.html
>> > > >models.py
>> > > >tests.py
>> > > >views.py
>>
>> > > > And then I can test the view by sending it the parameter 'test_blah'.
>> > > > It works fine, but it means I have to ship my app with that dirty
>> > > > "test_blah" folder.
>>
>> > > > Is there any other way to proceed?
>>
>> > > Check out django.contrib.auth.tests.views.py. The ChangePasswordTest
>> > > does some fancy footwork during the setUp and tearDown to install some
>> > > templates for testing purposes. You still need to ship the templates
>> > > as part of your project tarball, but they don't need to be in a
>> > > production-visible location - you can hide them away as part of the
>> > > testing infrastructure.
>>
>> > Another approach is to write a custom template loader that is used in
>> > your test settings file. There's nothing to say a template loader has to
>> > actually load a file. It has to return a template, given the name. You
>> > can do that however you like.
>>
>> > Regards,
>> > Malcolm
>>
>> Thanks also for this tip, Malcolm. Both approaches are quite elegant.
>
> I should add that the trickery used in ChangePasswordTest might be
> slightly better because it means the tests are self-contained, and so
> they don't depend on external parameters (e.g. the tests settings).
> The big advantage I see is that it makes the app more portable, at
> least as far as tests are concerned. Just tried it and it works like a
> charm!
If you want to get really fancy, you can actually combine the two
suggestions. Malcolm's suggestion is to introduce a 'test template
loader' which serves templates from memory (or, at least, from
somewhere other than a file). While Malcolm was suggesting that you do
this using a completely separate test settings file, you could also do
this using the setUp/tearDown trick to force the value of
TEMPLATE_LOADERS for the duration of the test case. This would remove
the dependency on an external settings file, while simultaneously
avoiding the need to have a directory full of test templates.
Whether it is worth the effort to set up this test infrastructure is
entirely up to you to decide, but I thought I'd point out the neat
trick just in case :-)
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Testing dynamic templates
On Tue, Nov 25, 2008 at 9:18 PM, Tim Chase <[EMAIL PROTECTED]> wrote: > >> Check out django.contrib.auth.tests.views.py. > > Is there some master index of documentation for "if you want to > test X, see Y.py or http://Z for an example of how to do it"? > where X is any of a number of Django features such as models, > views, templates, middleware, filters, template-tags, forms, > database-configurations, custom field-types, etc? > > I've read through > > http://docs.djangoproject.com/en/dev/topics/testing/?from=olddocs > > and there are some good specifics here (I'd expect that several > of the "see http://Z"; links would point here). However, it would > be nice to have a "testing cookbook" that would attack the topic > by "thing you want to test" (perhaps with both unittest and > doctest examples). > > Most of my learning-to-test-my-Django-app has happened through > trial and error, so any sort of "you want to test X, see Y" would > be helpful. ... and I'd like a pony. :-) Seriously - I agree. The testing documentation could certainly be improved - not just raw API, but lots of tutorials and cookbook stuff. As soon as I work out where I put my +4 Fountain of Infinite Time, I'll get right on this. In the meantime, if anyone wants to contribute documentation, this is certainly an area where help would be appreciated. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Testing dynamic apps
On Thu, Nov 27, 2008 at 8:33 AM, Julien Phalip <[EMAIL PROTECTED]> wrote: > > So, all this works pretty well. The 'fakeapp' app is loaded > dynamically, tables are created and the FakeItem model can be use in > my tests. > > But it feels dirty. The dynamically created tables can potentially > clash with some other applications (what if someone calls their app > 'fakeapp'?). To make it safer maybe I could give a random name to that > app (e.g. 'uytwe876435gjhgdfs0908'). > > Is there a cleaner way to do this? In a similar app (django-voting > [1]) there is a dedicated test suite, but I'd like to avoid that if > possible. You aren't the first person to have this need: this is logged as ticket #7835. The problem exists for any project that works at the meta level, working on models rather than with models. For example contrib.admin needs test models in order to validate that the admin can display different types of models correctly. contrib.admin works around the problem by putting the tests in the Django system test suite, rather than in the contrib app itself. Based on your description, this sounds like the same approach Django-voting has used. This approach works fine if you're willing to maintain an external test suite, but doesn't provide an integrated test suite that can be easily distributed with your app. This is one of those problems that I want to solve, but I haven't yet given a great deal of though into how to solve. I've got a few vague ideas banging around in my head about allowing test application and test model definitions to be included in the test module for an application, but those ideas aren't fully formed. Anyone that wants to help out with some concrete suggestions (and even better - code) is more than welcome to do so. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Testing dynamic apps
On Thu, Nov 27, 2008 at 11:21 AM, Julien Phalip <[EMAIL PROTECTED]> wrote: > > I'm keen to try to find some proper ways to fix this, but before I go > too deep into the bowels of Django's testing framework, I was > wondering what would be the criticisms you'd have about the "solution" > I came up with (at the start of this thread)? It sort of works without > patching Django, but is it acceptable? and if not, why? > > At this stage, it looks good enough to me except for two main points > that feel dirty: > 1) the test models should be unloaded after the test is run > 2) potential conflicts with external apps should be avoided. I will openly admit that I haven't given this much though, except in the abstract. I'm certain that there are many details and gotchas that I haven't thought of that implementation will reveal. Broadly speaking, I'm happy with the approach you are suggesting. The interface needs some work, though. I'd like to think that at an API level, it could be as simple as: class MyMetaTest(TestCase): apps = ['fakeapp','otherapp'] def test_stuff(self): ... where 'fakeapp' et al are submodules of the test module that contain a models.py definition. Obviously, the test applications need to be: - Added to INSTALLED APPS and the app cache on startup - Installed in the app cache before the syncdb caused by the pre-test database flush takes effect. You shouldn't need to manually invoke syncdb. - Removed from INSTALLED_APPS and the app cache on teardown I'm of two minds as to whether apps should define a complete replacement for INSTALLED_APPS, or if it should be a supplement to the INSTALLED_APPS that already exists for the project. This hits up against the recurring issue of testing as a per-app process vs testing as a project integration process. The name clash problem you describe shouldn't be that big an issue - you have the django-admin model validation tools at your disposal. You will probably want to put in some checks to make sure that validation only gets called once (so that you're not needlessly revalidating), but the validator should pick out any name clashes or other conflicts. Russ %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Raw SQL and model instances
On Fri, Nov 28, 2008 at 6:42 PM, Georg Göttlich <[EMAIL PROTECTED]> wrote:
>
> Hello everybody,
>
> this question has probably been ask quite often already, but I
> couldn't find anything proper on it. So here it is:
>
> Is there a way to feed the result cursor of a custom sql query back
> into the ORM, thus recieving model instances, as if you'd use a
> queryset?
Building an queryset isn't really possible, but if all you want is
model instances that are instantiated with data from your cursor, you
can instantiate model instances directly from row data. For example,
if your have an Author model, you could do something like the
following:
>>> cursor.execute('SELECT ...')
>>> row = cursor.fetchone()
>>> a = Author(*row)
At this point, a will be a fully populated Author instance,
indistinguishable from one retrieved using a queryset.
The caveat on this technique is that the SELECT you execute using the
cursor to obtain the row must contain all the columns in your model,
specified in the same order that your model defines them. This
includes the auto-added id column, if appropriate. If you're uncertain
which fields will be required, and in what order, Author._meta.fields
contains the list that Django will expect.
If you need to return multiple rows and produce multiple instances,
iterate over the returned rows and construct an instance for each row,
storing the result. The end product won't be a queryset, but it will
be an iterable collection of Django model instances.
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Django revision for ORM aggregation patch
On Mon, Dec 1, 2008 at 2:04 AM, Ariel Mauricio Nunez Gomez <[EMAIL PROTECTED]> wrote: > Does anybody know which revision of django works with the latest patch in > the ticket #3566 > http://code.djangoproject.com/ticket/3566 The patch on the ticket was constructed against a trunk revision just prior to 1.0 release. Since then, I have been working on this ticket in my local git repository. While there are some minor variations between the published patch and my current working version, the changes I have made aren't particular significant, so I'm not aware of any merge problems that you should be having. I should be in a position to publish a git repository with my work in progress in the next day or so, which will remove the need for anyone to apply the patch manually. When I push the repository, I'll announce on the ticket and on django-developers. Watch this space. > I tried unsuccesfully with django 1.0rc, 1.0 and 1.0.2, everytime different > rejections, and when I try to fix them by hand I always get a 'SELECT FROM > ...' invalid clause error. This error isn't one I can recall seeing during my work, so I'd need to see more detail to help out here. The only error I am aware of with the patch as published is that one of the test cases causes problems with MySQL due to a quoting problem with a column name with a space in it. This arises as a ProgrammingError during the test suite, not an invalid clause error. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django revision for ORM aggregation patch
On Mon, Dec 1, 2008 at 9:13 AM, Ariel Mauricio Nunez Gomez <[EMAIL PROTECTED]> wrote: > >> I should be in a position to publish a git repository with my work in >> progress in the next day or so, which will remove the need for anyone >> to apply the patch manually. When I push the repository, I'll announce >> on the ticket and on django-developers. Watch this space. > > That'd be great, thanks a lot. FYI - the repository is now live: http://github.com/freakboy3742/django/tree/aggregation See the notes on ticket #3566 for details about the code in that repository. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: djangobook.com, chapter 5, __init__() got an unexpected keyword argument 'maxlength'
On Mon, Dec 1, 2008 at 2:04 PM, djan <[EMAIL PROTECTED]> wrote: > > Hello, > > I'm following along with djangobook.com, and I have a problem in > chapter 5 that I cannot resolve. I am using OpenSuSE-11.0, Python > 2.5.2, sqlite3-3.5.7-17.1 (and incidentally, this same error occurs > with MySQL). > TypeError: __init__() got an unexpected keyword argument 'maxlength' The Django book is based on Django Version 0.96; we have since released Version 1.0, which introduced a few backwards incompatibilities - in this case, the 'maxlength' was renamed to 'max_length' for consistency with other parts of Django. A guide to porting 0.96 applications to 1.0 can be found here: http://docs.djangoproject.com/en/dev/releases/1.0-porting-guide/ A full list of backwards incompatibilities between version 0.96 and 1.0 can be found here: http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: How to use Fixtures and/or Initial SQL for project auth_user data?
On Sat, Dec 6, 2008 at 1:54 AM, Jeff Kowalczyk <[EMAIL PROTECTED]> wrote:
>
> During early prototyping, I'm relying on specific auth_user content in
> the project admin, as my app model use User as a ForeignKeyField.
>
> Project layout is:myproject/myapp
>
> Initial SQL myproject/myapp/mymodel/sql/mymodel.sql works fine, and
> I'm interested in initial_data.[xml/yaml/json for the same purpose.
>
> Is there an equivalent location under the project (or app) level for
> loading auth_{user,user_user_permissions} data, including the one
> superuser I always want configured?
This is one of the use cases that fixture loading was designed for.
Put your user and permissions into a fixture called initial_data, and
it will be automatically loaded whenever you run syncdb. If you don't
want it to be automatically loaded (which is a good idea if you're
dealing with passwords), choose another fixture name, and manually
load the data using ./manage.py loaddata.
http://docs.djangoproject.com/en/dev/howto/initial-data/
http://docs.djangoproject.com/en/dev/topics/serialization/
http://docs.djangoproject.com/en/dev/ref/django-admin/#loaddata-fixture-fixture
You can write your fixtures by hand if you want; alternatively, you
can use the dumpdata command to dump the current database contents (or
part of the database):
http://docs.djangoproject.com/en/dev/ref/django-admin/#dumpdata
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: custom distinct() method
On Tue, Dec 9, 2008 at 7:05 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > please, maybe anyone now how to perform distinct() filtering for > certain attribute(column), not the whole objects(rows)? :) First off - patience. Only 10 hours passed between your original request and your repeat. This is an international mailing list, we're spread all over the globe, and we're all volunteers. Sometimes is may take a day for someone to find the time to help you. If you need a more immediate response, consider trying in the IRC channel. > In case not - please tell me what's the best practice when coming to a > situation when django orm is not powerfull enough. Can writting custom > sql queries become a serious problem later on? i could, of course, > write a custom SQL query and get the result as tuples, but that's only > for representation of data, manipulation gets realy tricky, as you > can't refer to the given data as the objects of django. And there is > that feeling that after the first custom sql query, 10 more new will > be neccessary later on and you may end up writting all the webapp the > good-old SQLObject way. The Django ORM is good for writing the very common query types. However, if you can't bend the ORM to do what you need, raw SQL is always an option. Will this become a maintenance hassle? Maintaining non-ORM code is always going to be a little bit of a hassle, but if the alternative is not finishing a project because your code doesn't meet your requirements... If the issue is converting SQL cursor data into Django objects - that's trivial - just take the row of data from the cursor and use it to instantiate an object instance: cursor = self.connection.cursor() cursor.execute(sql, params) row = cursor.fetchone()[:-len(results.ordering_aliases)] newobject = MyObject(*row) Regarding your specific problem - I think the first step is to clarify in your own mind what it is that you want. Your example doesn't match up with the code you are giving. You say that the Django ORM doesn't do what you want, but the SQL sample you give: SELECT DISTINCT column1, column2 FROM table WHERE column1='name'; is exactly what is produced by the query: Table.objects.filter(column='name').distinct() If you don't believe me, print Table.objects.filter(column='name').distinct().query will tell you what is going to be executed by the cursor. It sounds like the first step in your case is to work out what SQL you want. Once you have that worked out, we can tell you your options with the Django ORM. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: custom distinct() method
On Wed, Dec 10, 2008 at 7:58 PM, jamesjacksonn...@gmail.com
wrote:
>
> One example is worth thousand explanations, so, let's say the
> situation is as follows:
>
> class example(models.Model):
>artist = models.CharField(max_length=765, blank=True)
>song_name = models.CharField(max_length=765, blank=True)
>id = models.IntegerField(primary_key=True)
>
> Three objects are created/save to a mysql db:
> 1 Django Reinhardt Liza
> 2 Django Reinhardt Minor Swing
> 3 Django Reinhardt Nuages
>
> example.objects.filter(artist="Django Reinhardt").distinct() returns
> all three objects, by making SQL query:
> SELECT DISTINCT `mainapp_example`.`artist`,
> `mainapp_example`.`song_name`, `mainapp_example`.`id` FROM
> `mainapp_example` WHERE `mainapp_example`.`artist` = Django
> Reinhardt .
>
> Lets say my goal is to get the list of (distinct) artists in a
> database, and it is reached by commiting query:
> SELECT DISTINCT `mainapp_example`.`artist` FROM `mainapp_example`
> WHERE `mainapp_example`.`artist` = Django Reinhardt .
> Only one row is returned - Django Reinhardt. Is it possible to get the
> same value using django-orm?
> That's probably how i was supposed to ask before.
Ok; now I understand the problem...
> Now i'm trying to get why this might be impossible - django queryset
> is probably supposed to (always) return objects, and in this case, its
> tuple ('Django Reinhardt',) or dictionary {'column': 'artist,
> 'row1':'Django Reinhardt'} i do expect to be returned. But please
> correct me if i'm wrong in past sentence, or anywhere in the post.
... and you've preempted my answer. What you're asking for can't be
retrieved with a simple query.
In order to get the distinct artist names, you need to restrict the
columns named in the select. You can do this with a values()
statement:
Song.objects.values('artist').distinct().
This will return a ValuesQuerySet, which acts much like a list of
dictionaries; each dictionary will have a single key-value pair. In
your example, the result would be something like:
[{'artist': 'Django Reinhardt'}]
If you're dealing with a single unique field (artist, in this case),
you can simplify the structure of the return value this by using a
call to values_list(), instead of values(). See the docs for more
details.
If all you want is the list of unique names, that's all you need to
so. However, in order to retrieve a QuerySet populated with full
Django objects, you need to put every column name in the SELECT. This
is done implicitly when you run Model.objects.all(), or any other
non-values() queryset.
This means that the requirements for the distinct call conflict with
the requirements for the object call. You can't make a simple 'SELECT
x FROM y WHERE z' where x satisfies both requirements.
However, you can do it by embedding one query in another - that is,
issue one query to get a list of unique names, then a second query to
retrieve a list of full objects that match those names. This can be
achieved in several ways, but something like the following should do
the trick:
Song.objects.filter(name__in=Song.objects.values_list('artist', flat=True))
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: order by field length?
On Wed, Dec 17, 2008 at 9:04 AM, David Lindquist
wrote:
>
> I encountered a scenario where I need to query the database for a
> list of names sorted by length. In SQL this is easy:
>
> SELECT name from distributors_distributor ORDER BY LENGTH(name)
>
> Instead of writing raw SQL in my view, I am doing this:
>
> names = [x['name'] for x in Distributor.objects.values('name')]
> names.sort(lambda x, y: len(x) - len(y))
>
> Is there a better way of doing this? Or rather, is there a way to use
> the QuerySet API to produce the equivalent of the SQL above?
Something like this should work:
Distributor.objects.extra(select={'length':'Length(name)'}).order_by('length')
This uses an extra() clause to add a length field to the select that
is being retrieved, then uses that length column for sorting purposes.
It does involve a little raw SQL leaking through to your code (the
call to Length()), but not as much as a completely raw SQL query would
require.
This class of problem could also be addressed by the F() notation that
has been proposed in #7210 and accepted for v1.1. This particular use
case wasn't on the original todo list, but it should be in the realms
of possibility.
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: SyncDB failure
On Wed, Dec 17, 2008 at 9:30 PM, James PIC wrote: > > Is it worth reporting the bug? It isn't entirely clear what "the bug" is. All that you have given us is an error message, and a solution that you have worked out. What you haven't given us is enough detail to reproduce the problem for ourself. We don't know what your project looks like, what is contained in your apps, if there is any strange synchronization logic being triggered - all we have is an error message. A cut down project definition that can't be synchronized would be the minimum requirement before you reported this bug in a ticket. However, at a guess, I'm going to say that the problem has been caused by your choice of model names. You appear to have named one of your models something like TypedEInformationComplementaireContact. This is a pretty long class name, and it is overflowing a column somewhere that is using the class name as a starting point. Your proposed fix (increasing the size of the columns) is really just deferring the problem. No matter what maximum size we pick, someone will choose a model name that will overflow it. I would have thought a 50 character limit was plenty, but obviously I was wrong. Your solution also suffers from the problem of backwards compatibility - there is a lot of existing code out there that relies on the existing size definition. A better solution would be to come up with a name munging scheme that guaranteed to give unique permission names that will always fit into the available space. 50 characters is plenty to establish a unique name; we already perform a similar munging with the names for database constraints. Of course, the simplest solution is for you to pick shorter class names, and for us to document the limitation. This solution has the additional benefit of enforcing good programming practice. Having descriptive class names is good, but I for one wouldn't derive much joy from using an API that had class names that spanned 50% of the width of a 80 character terminal :-) 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: FTP'ing without locking
On Thu, Dec 18, 2008 at 6:15 AM, Greg Taylor wrote: > > This is somewhat of a core Python question with a Django twist. I'm > running mod_wsgi and am trying to figure out how to FTP a file from my > Django app to a remote host without locking the thread up. I've tried > something like: > > from subprocess import Popen > print Popen(["python", command_str, "53363", "1"]).pid > > I'm sure there's a much better way to do what I'm trying to. I thought > about threading it off, but wouldn't the wsgi process have to stick > around for the thread to return? You can't really do any long lived processing in a view. Threading won't really solve the problem, for the exact reason you have identified. The solution here is to use a separate worker process. Your view creates 'jobs' on a queue describing what needs to be FTP'd and from where. A completely separate process then polls the queue and performs the actually downloading. The queue processor is completely decoupled from the view and doesn't prevent the view returning quickly. One simple approach for implementing the queue is to use cron to perform regular polling; there are many other possible solutions, especially if you're sensitive to the latency that cron would introduce. If you want to get extra fancy and you want to provide download feedback, you can use a second, AJAX-style view to monitor the state of the queue. This lets the user know what progress has been made on their download without locking the webserver. 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: TextMate Django Bundle
On Thu, Dec 18, 2008 at 7:11 AM, Adam Nelson wrote: > > Does anybody have this working in TextMate? > > "Python Django Templates.tmbundle" > > From http://macromates.com/svn/Bundles/trunk/Bundles/ > > I've installed other bundles and the Python Django.tmbundle, but the > Templates one simply doesn't appear in the Bundles menu. I'm not sure what is going wrong for you - the Django and Django Templates bundles both work fine for me. 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: FTP'ing without locking
On Thu, Dec 18, 2008 at 7:55 AM, Greg Taylor wrote: > > Yeah, I was afraid this would be the case. The interval polling script > was something I really wanted to avoid. > > I can't believe this isn't possible, though. I assume this is a Django > limitation of some sort? Ok, then. How would you do it in PHP? Rails? Any other web framework? The limitation here isn't Django per se. It is a fundamental design contstraint of the web itself. HTTP essentially requires that all requests can be satisfied very quickly. This pretty much eliminates the possibility of having long-lived processing as part of request handling. Strictly speaking, this isn't even a limitation of web applications. Regardless of the programming paradigm, you shouldn't arbitrarily start a long lived processing task. In order to give good UI feedback, you should always start a long lived task in the background, and use the foreground processing to monitor the status of the background task. Web frameworks impose certain unique restrictions on the way this pattern is realized, but the base requirements are fundamentally the same as any other programming paradigm. 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: double logging in unittest
On Thu, Dec 18, 2008 at 5:05 PM, knight wrote: > > Hi, > > I have unittests in my django applications and I have a strange > behavior: > When I run the tests, I am getting each print-out to log from my > application twice. > I am using the standard python logging libraries. > Does anyone know this issue? There shouldn't be anything in the unit test framework that modifies the operation of logging. In order to provide any more advice than this, we will need to see a small example that demonstrates the behaviour. 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: Using Content Types With Test Databases
On Mon, Dec 15, 2008 at 11:24 AM, Mark wrote: > > Hello, > > Are there any comments on the issue I describe below? > Aside from issue 7052 in the tracker: > > http://code.djangoproject.com/ticket/7052 > > I'm a new user of Django so I may be doing something > wrong. You're not doing anything wrong. The issue you are describing here isn't a new issue, either - it is exactly what #7052 is describing. Regarding your proposed solution - I'm sure it works, but it's not the right solution. The problem you have observed with content_types is part of a much larger problem. Ticket #7052, for example, highlights that the same problem exists with Permission objects in the auth contrib app. The larger problem is the serialization of content that is dynamically created as a result of a post_syncdb trigger. The solution here isn't to make a special case of content_type (or any other affected type). The solution is to find a reliable way to serialize dynamically created content. The ticket for #7052 describes one possible solution - modifying the serializers so that they can dynamically query for content that is known to be dynamically reated. Suggestions for other solutions are welcome, but keep in mind that they must be general solutions for the problem (not making special cases of content_type or any other data type), and they must be backwards compatible. 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: Putting tests in a tests folder
On Fri, Dec 19, 2008 at 11:32 PM, Martin Lundberg
wrote:
> Hello everyone!
>
> What do I need to do to be able to put my tests in a folder (called "tests")
> inside my application folders and make django run them?
>
> I want something like:
>
> /project/app1/tests/module_tests.py
> /project/app1/tests/module2_tests.py
> /project/app2/tests/module_tests.py
> /project/app2/tests/module2_tests.py
This directory structure will pose no problems - I use a very similar
structure on many of my projects.
However, you will need to make some minor additions. You will need two
additional files - /project/app1/tests/__init__.py and
/project/app2/tests/__init__.py. These tell Python that tests is a
module that can be loaded.
Then, you need to tell Django how to discover the tests. There are two
options here.
Firstly, you can directly import tests from the individual modules
into the tests namespace. This means putting the following into your
__init__.py file:
from app1.tests.module_tests import *
from app1.tests.module2_tests import *
This manually pulls all the tests from the individual test files into
a single namespace. If you want to use doctests, you will also need to
register the doctests, using the __test__ identifer:
__test__ = {
'module_tests': module_test_docstring,
'module2_tests': module2_test_docstring
}
where module_test_docstring etc is the name of a string containing
your test content. See
http://docs.python.org/library/doctest.html#which-docstrings-are-examined
for more details on registering doctests.
The second approach is to define a suite() method in __init__.py. See
http://docs.python.org/library/unittest.html#organizing-test-code for
more details on how to define a suite.
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: django deserialize and save new model object from xml
On Wed, Dec 24, 2008 at 6:33 AM, dick...@gmail.com wrote: > > looking at the serialization serializers, is is possible to save "new" > instance of a model object represented in xml? > > i'm getting an error: > > node is missing the 'pk' attribute, but basically, there > isn't one, because i don't want the object retrieved from the db, i > want to instantiate it from the xml, then save it? > > possible? It isn't possible right now. However, fixing this by inserting some error handling for the 'object doesn't have pk' case should be relatively simple to implement. Feel free to open a ticket suggesting this. If you're feeling adventurous, it should be a relatively simple problem to fix yourself. The serializers are mostly self-contained, so if you're looking for a simple way to get involved with Django development, this would be a good candidate. Work out the changes required, write a test case for the test suite, and you could have your problem solved and your name in the credits. If you do decide to have a try at solving this problem, keep in mind that there is a second side to the problem - once you can serialize an object without a primary key, you also need to be able to deserialize an object that has been serialized without a primary key. 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: Fastest way to import datas into a database
On Thu, Dec 25, 2008 at 9:02 AM, bsergean wrote: > > Hi all, > > I'm populating my database manually using a script that create ORM > objects and save them... I have a lot of datas and it's fairly slow. > I'm wondering what is the best way to speed this up. > > From > http://docs.djangoproject.com/en/dev/howto/initial-data/#howto-initial-data > I see there are two alternatives. > > * Using fixtures > I could create a big json files (or several), and then load them. Will > it be smart and do the smallest number of query, or a bunch of > queries ? This will essentially be no different to your 'create ORM objects' approach. Internally, Django uses ORM objects in the deserialization process, so if you are seeing problems manually creating ORM objects, the same problems will probably exist with deserialization. > * Or using raw SQL ? (I'm using postgres, and I saw you can do an > INSERT command with multiple rows. Is it a good way to speedup > things) ? Assuming you can automate the production of the SQL and, this will always be the fastest approach. However, the price you pay is the convenience of dealing with the ORM. You will need to balance the costs for your own circumstances. A third option that you haven't considered is that you may not be using Django properly :-) An often forgotten feature of Django is that When DEBUG is enabled, Django logs every command that goes to the SQL backend. As a consequence, if you run a long lived script, you will see a slowdown as memory gets eaten up by the SQL activity log. If you disable DEBUG during your production data load, logging is disabled, and you should find that performance improves dramatically. 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: Is there any possibility that one project connect with more than one databases?
On Thu, Dec 25, 2008 at 5:41 PM, David wrote: > > Dear all, > > I am a newbie in Django and python, now trying to construct a website > with more than one databases on the backend. > > My question here is, if there any possibility that using 2 different > databases inside one project(website)? > If yes, how can I do this? Right now, the state of Django with regard to multiple-database support is essentially this: * If you need to ask, it can't be done. * If you know how the internals of Django work, it _can_ be done, but it's isn't completely trivial. Adding formal API support for multiple databases has been discussed many times over the history of Django's development. A recent discussion came close to resolving the major API issues, but didn't resolve them in time for consideration for the Django v1.1 release. I would expect that multiple database support will be a likely candidate for v1.2. Search the archives of django-users and django-developers if you want to know more. > If no, why does Django framwork not support this requirement? Because this is a volunteer project, and it hasn't been a priority for any of the core developers to date. If you want to volunteer to help, feel free to do so. 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: How do I make Django evaluate a ForeignKey for json serialization?
On Sat, Dec 27, 2008 at 2:11 PM, adambossy wrote:
>
> I have a model that refers to a ForeignKey, e.g.:
>
> class Template(models.Model):
> type = models.ForeignKey(Type)
> ...
>
> class Type(models.Model)
> name = models.CharField(max_length=32)
> ...
>
> I can fetch these objects fine using the model API.
>
> t = Template.objects.get(id=1)
> print t.type
>>>
> print t.type.id
>>> 3
> print t.type.name
>>> TemplateType3
>
> If I serialize these, I cannot get 'name.' I know Django lazily
> retrieves these, but even by iterating or calling t.type.name, they
> are unavailable during serialization. Is there any way to have Django
> evaluate the ForeignKey object so that I can retrieve the field,
> 'name?' I need fields to contain "name": "TemplateType3" (or whatever
> it may be)! :)
>
> from django.core import serializers
> print serializers.serialize('json', Template.objects.get(id=1))
>
>>> {
>"pk": 1,
>"model": "template",
>"fields": {
>"type": 3
>}
>},
>
It isn't entirely clear what you're trying to do. Do you want to
change the Django serializers so that they output:
"type": "TemplateType3"
If this is the case, then you will need to write your own serializer.
Django serializes objects in a specific way, optimized for
deserialization later on as fixtures. This output format won't suit
many applications. If you need a different format, you will need to
write a serializer that outputs in the format you require. Django
ships with SimpleJSON, so you can build serialized output from
primitives if need be. You could also use Django's serialization
library to write your own serializer that outputs in a format of your
choice. If your desired output format is similar to Django's default
format, you may find that you can use django/core/serializers/json.py
as a starting point for this implementation.
Alternatively, are you trying to manipulate a deserialized object in
some way? If this is the case, you will need to provide more specific
details on what it is you are trying to achieve.
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: Calculate and store the average rating
On Sat, Dec 27, 2008 at 7:48 AM, eldonp2 wrote: > > Is there a way to calculate and store the average rating in this > example: It's not entirely clear which part of this problem you want help with. - Computing the average rating. The brute force approach would be to iterate over the relevant related objects and compute an average. A smarter approach would be to use SQL to compute the average. - Storing the average in the related model. This could be as simple as saving an instance of the BookRatings model after computing the average. You could also use signals or save() overriding to automate the update of the BookRatings model. - Model design. It's not entirely clear why you would want to denormalize the average values, and then put them into a separate model. If you provide a better description of the problem you want help with, what you have already tried, and what problems you have experienced, we may be able to provide a more meaningful answer to your problem. 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: Traceback in the ``runserver`` console
On Sat, Dec 27, 2008 at 2:32 AM, Fridrik Mar Jonsson wrote: > > Hi Djangonians, > > I recently had an instance where it would have been really convenient > to see the error and a traceback in the ``runserver`` console instead > of just a single line telling me that the request returned a 500 > error. > > In the event of blind debugging, where a 3rd party tool is performing > a request that renders in an error, is there a Django mechanism or > extension that allows you to catch any exceptions that occur during a > page load and redirect them to the ``runserver`` console in addition > to displaying them in the template? There are two options I can think of on an unmodified Django install. Firstly, write a middleware that implements process_exception(). This middleware will get invoked whenever an exception is raised as part of the view; the middleware method will be the exception as one of the arguments. http://docs.djangoproject.com/en/dev/topics/http/middleware/#process-exception Secondly, write a listener for the got_request_exception signal. This signal is fired whenever an exception other than 404, Permission Denied, or SystemExit is raised. http://docs.djangoproject.com/en/dev/ref/signals/#django.core.signals.got_request_exception > For an optimistic moment I thought ``--traceback`` was a bit > promising, but then it turned out that it doesn't really seem to do > what I expected in the case of ``runserver``. I even considered > switching to e-mail tracebacks but ended up writing a client to mimic > the 3rd party tool's functionality instead. When I read this I went and had a look at the code, and it appears you are correct. ``--traceback`` exists as a top-level command option, but it doesn't appear to be exploited at all in runserver. This actually surprised me - it seems like a reasonable suggestion for an improvement. Feel free to open this as a ticket (and if you're really adventurous, work on a patch :-) 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: Invalid block tag: 'get_comment_count'
On Sun, Dec 28, 2008 at 12:27 AM, Florian Lindner wrote:
>
> Hello,
>
> I'm trying to use the comment framework from Django 1.0.2.
>
> I've followed all the steps in
> http://docs.djangoproject.com/en/dev/ref/contrib/comments/
>
> (added it to installed apps, added to urls.py and loaded in the
> template) but I get:
>
> TemplateSyntaxError at /blog/1/
> Invalid block tag: 'get_comment_count'
>
> from:
>
> {% get_comment_count for object as comment_count %}
django.contrib.comments is an extension application, so the template
capabilities provided by this application aren't included in the
default template tag set. In order to use {% get_comment_count %} in
your template, you need to direct the template engine to load the
comment template tags. This means putting {% load comments %} at the
start of the template that is using {% get_comment_count %.
This is covered right at the start of the page you referenced:
http://docs.djangoproject.com/en/dev/ref/contrib/comments/#comment-template-tags
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: How do I make Django evaluate a ForeignKey for json serialization?
On Sun, Dec 28, 2008 at 5:32 AM, adambossy wrote: > > Russ, > > Thanks for the reply. Specifically, I am wondering if there is some > feature of the Models API that allows me to retrieve the foreign key > object so that it is included in the serialized string. That is, > without writing my own serializer (which I suspect I may have to do). The serializer is decoupled from the Model API, so your question is unrelated to the model API. Serialization exploits the model metatdata embedded in models; the issue in this case is that the data extracted from the model by the serializer doesn't meet your requirements. You want to have a different serialization format (i.e., you want to roll out serialized objects in a different format to that provided by default). This means you will need to write your own serializer. Looking for deeper solutions to this problem - Ticket #4656 possibly describes part of your problem - this ticket describes an enhancement that would allow the serializer to follow. This would be much like the select_related() operator on querysets, but for serialization. This ticket hasn't seen any activity for a while, but it has been accepted for inclusion as soon as a working implementation is available. There is also a lingering ticket idea floating around - it has been suggested many times that Django's serializers are not flexible enough - that your use case should be a matter of configuring Django's serializer, rather than writing a new serializer from scratch. In principle, I have no objection to this idea - but I am yet to see a good proposal for what such configuration would look like. > I'll keep tinkering... Let me know if you have any ideas. Let me know if you have any :-) 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: Django serializers and local/inherited model fields
On Wed, Dec 31, 2008 at 4:27 AM, psj wrote: > > Django's base serializers only serialize a model's local fields, not > inherited ones, which seems odd at first blush (if an Employee is a > Person, and a Person has a name, wouldn't I be likely to want to see > the Employees' names by default?) > > This looks straightforward to work around, but just wondering if > there's some gotcha I'm not thinking of here. Was this a performance > decision? This is one of the areas that reveals that serialization is a bit of a 'one-trick pony'. Serialization works really well for fixtures, but it isn't particularly flexible when it comes to other serialization use cases. In this case, the serializers are serializing exactly what the database requires - the output is a JSON representation of the database table contents. The primary reason for this is the deserialization process. If you include the 'Person' attributes on a serialized Employee, it becomes more complex to determine whether you need to create a new Person object when deserializing the Employee, and to disable creation of the parent object instance when it isn't required. So - if you want to fully serialize an Employee, you also need to serialize the underlying Person object as well, and each model is responsible for serializing their own attributes. Expanding the usefulness of the serializers is something that we would like to address. If you search the ticket database, you will find many suggestions floating around for improving the capabilities of the serialization process. However, it's not a trivial problem, and it will take some serious design work. Any offers to help out in this area would be gratefully accepted. 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: Getting SQL from QuerySet
On Wed, Dec 31, 2008 at 5:11 AM, Info Cascade wrote: > > Hi -- > > I am getting intermittent errors on certain database queries on our > production server. > I am having a hard time duplicating them (most of the time they run > okay, only sometimes on the production server am I receiving exception > messages), > so I want to log the SQL query itself and see what it is, and why it > might be failing. > Is there some way of seeing what SQL statement will be executed by a > QuerySet before actually executing it? Yes. If you have the query: >>> Author.objects.filter(...) then the following: >>> print Author.objects.filter(...).query.as_sql() will print the SQL that results from the query. Another approach is to inspect the query log. If debug is enabled in your settings, then: >>> from django.db import connection >>> connection.queries will print a list of all queries that have been passed to the database. 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: specify alternative settings.py file at startup
On Wed, Dec 31, 2008 at 11:45 AM, dick...@gmail.com wrote: > > i'm confused on the --settings option on manage.py. > > if i have a project call foo, i'd have in ./foo/settings.py > > to run: python manage.py runserver 8080 > > let's say i have a bar.settings.py which contains different values > (like test database to use or something), i'm trying to run: > > python manage.py runserver --settings=bar.settings 8080 (and maybe > combintations of), but keep getting some derivations of: "Could Not > Import settings...is it on the sys.path, no module named bar.settings. The cause of the confusion here is the name of your settings file. Python uses dot notation to specify module hierarchies. When you specify bar.settings, Python expects to find a directory named bar with a file called settings.py in that directory. If you rename your settings file bar_settings.py (or something else that is compatible with Python module naming) you should stop getting the error you report. 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: about templatetags
On Thu, Jan 1, 2009 at 8:18 AM, Alan wrote: > Happy new year List! > So, I have in a project several apps and they basically use the same > templatetags. I found out by luck that I just need to define it in one > application, something like: > app1/ > models.py > ... > app2/ > templatetags/mytags.py > models.py > ... > and app1 will use mytags. > Is my inference right? Well it's working here. If so, why templatetags has > to be inside apps folder? Why not at the same level of 'template' folder? > It sounds inconsistent to me, or I am probably missing something here. Your usage is correct i.e., you only need to define the template tag once. However, I'm a little confused as to why you see it as inconsistent. Templates will tend to be site/project specific, so it makes sense that templates aren't associated with the individual applications inside a project. Hence, projects tend to have a top level templates directory that are independent of the applications in use. Template Tags, on the other hand, are just blocks of code, so they need to be reusable. The unit of reusability in Django is the application. A template tag is defined as being part of App2, but that is really just a way of getting the template tag registered - it doesn't limit the places where the template tag can be used. The possible source of confusion is that there isn't any namespacing of template tags - there is only the single global templatetag namespace. Introducing namespaces for template tags is a subject that gets raised occasionally - search the archives and the ticket database if you want to see the state of play of that discussion. 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: SimpleDB Support
On Thu, Jan 1, 2009 at 3:21 AM, Travis Reeder wrote: > > I've read some old threads discussing this, but I'm wondering if any > progress has been made? There certainly isn't anything official to report. Adding support for SimpleDB, CouchDB, Google AppEngine, HBase, or any other non-SQL data source is on the "nice to have" list, but not a current development priority of the core Django team. For a list of the current development priorities, see the v1.1 feature list [1] However, this is a volunteer project - if anyone wants to contribute a non-SQL data backend, we're only too happy for their contribution. If integrating a non-SQL backend requires changes to the Django core, we are willing to entertain any well explained proposal. [1] http://code.djangoproject.com/wiki/Version1.1Roadmap 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: manage.py test without using a database?
On Wed, Dec 31, 2008 at 7:08 AM, Bo Shi wrote: > > Hi, > > One of our django applications does not use django's ORM. Is there a > way to run > > ./manage.py test my_app > > Such that it does not perform test database setup? There are two ways that you could do this. The first would be to define a custom test runner that skipped the database setup phase. django/test/simple/run_tests() will give you a model for what needs to be in a test runner; take a copy of this method (removing the database setup portions) and follow the instructions in [1] The second approach would be to define a dummy database backend that didn't complain about a database not being defined. django/db/backends/dummy gives you a starting point for this. Either way, you will need to make changes to your settings file. Neither of these approaches will fall in to the "if I'm only testing my_app, don't bother setting up the database, otherwise set up the database as normal" category. [1] http://docs.djangoproject.com/en/dev/topics/testing/#using-different-testing-frameworks 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: about templatetags
On Fri, Jan 2, 2009 at 1:01 AM, Alan wrote: > Hi Russell > Thank you very much for your explanation. > I understand that being an apps reusable, should it be so its templatetags > and so, probably, the best place is in apps folder. > However, in my case, where all my apps needs the same templatetags, I would > like to have the option of defining templatetags under project folder > instead of an apps folder, just for the matter of organisation (which I > called 'consistency'). You're missing my point. The _project_ isn't a unit of reusability, so a project level directory is the wrong place to put this. If you have a bunch of template tags that you want to share between multiple apps, and it doesn't seem appropriate to tie the template tags to one specific app, then create a _new_ application to store just the template tags. The markup and webdesign contrib apps are examples of exactly this practice. These apps don't define models or views, they just provide useful templating resources that can be reused. 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: is it possible to provide initial data for a model with a foreign key to User model?
On Sat, Jan 3, 2009 at 3:01 AM, adrian wrote:
>
>
> I happen to have a bunch of models that all have foreign keys, but
> there is an order in which they could all be initialized. I have
> figured out how to initialize the built-in User model using Json data,
> but I can't initialize any models that refer to it using a foreign
> key. Is this possible and if so how?
Yes, it is possible. If you have a model something like:
class Person(Model):
user = ForeignKey(User)
name = CharField(...)
this will serialize something like:
{
"model": "myapp.person',
"pk": 1,
"fields": {
"user": 3,
"name": "Fred"
}
}
The reference to a user is just the primary key of the object you want
to refer to. If you want a more comprehensive example using your own
models, try creating some instances using the Python API, then use the
manage.py dumpdata command to produce sample fixtures.
Generally speaking, you don't need to worry about the order of
initialization. In your fixture, you can define the Person then the
User, or the User and then the Person - it doesn't matter.
If you're using SQLite or MySQL with MyISAM tables, there is no
referential integrity to worry about, so you can create a Person that
refers to a User that doesn't exist yet. As long as you eventually
create the User, you won't have any problems.
If you're using Postgres, all the fixtures are loaded in a
transaction, and referential integrity isn't checked until the end of
the transaction. As long as the Person and the User are both loaded at
the end of fixture loading, the order in which they are created
doesn't matter.
The only exception to this rule is MySQL with InnoDB tables - which,
because of its retarted referential integrity, insists on checking
references at the end of every commit, rather than at the end of the
transactional block. This means that you have to manually check that
the fixture with an ordering such that the User is loaded before the
Person.
Until MySQL fixes its referential integrity rules for InnoDB, this
limitation can't be avoided in the general case. Any form of circular
reference between models will always pose difficulties - there is no
way to provide an ordering that is guaranteed to load successfully.
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: Why Django doesn't force testing?
On Mon, Jan 5, 2009 at 9:04 PM, HB wrote: > > Sure, I mean encourage not force :) Ok, then - what could we do to encourage testing? We have a test framework; it is documented, there are plenty of blog entries around that discuss how to use it, and there are some utilities in the community (such as testmaker) that can be used to assist. However, if there is something else we could be doing to encourage more people to use the test framework, I'm all for it. I have two ideas that I've been intending to work on since I had some discussions at DjangoCon. In the interests of full disclosure, I've just opened tickets describing them; time permitting, they will be in place before v1.1. 1) #9963: Include a dummy test as part of the empty stub application that is produced by manage.py startapp. This is a fairly simple addition, but well worth it IMHO. 2) #9962: Write a official tutorial on testing. This one is a little more effort. If someone wants to volunteer a draft before I get around to writing one myself, I'm happy to proofread any offerings as candidates for trunk. Of course, any other suggestions are more than welcome. 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: django and database views
On Mon, Jan 5, 2009 at 11:31 PM, drakkan wrote: > > Hi all, > > I mapped a database view in django model as a normal database table, ... > there is a know workaround for this? any way to declare read only the > model? In short, no. Django doesn't currently provide any support for database views. There might be a few tricks you could do (such as redefining delete() to be a no-op on the view model and on a custom default manager), but these certainly aren't tested or proven suggestions. 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: django and database views
On Tue, Jan 6, 2009 at 8:11 AM, drakkan wrote: > > > > On 6 Gen, 00:06, "Russell Keith-Magee" wrote: >> On Mon, Jan 5, 2009 at 11:31 PM, drakkan wrote: >> >> > Hi all, >> >> > I mapped a database view in django model as a normal database table, >> ... >> > there is a know workaround for this? any way to declare read only the >> > model? >> >> In short, no. Django doesn't currently provide any support for database >> views. >> >> There might be a few tricks you could do (such as redefining delete() > > thanks but this didn't work I already redefined delete as follow: > > > def delete(self): >pass > > but the error is the same > > >> to be a no-op on the view model and on a custom default manager), but >> these certainly aren't tested or proven suggestions. Did you redefine just on the model class, or did you do the default manager change as well? Thinking about this a little more, you will also need to define your own custom QuerySet class that disables delete(). In short, this isn't going to be easy unless you're willing to get your hands dirty and dig into the code a little. 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: license problem
On Tue, Jan 6, 2009 at 7:46 AM, Sebastian Bauer wrote: > > Hello, i want to release some code, but i have one problem: > > how impel peoples to send me back patches? > > Any suggestions are welcome :) First, participate in the dark arts until to ascend to the level of minor god. Then, use your newfound ability to fling lightning bolts at the mortals to compel people to contribute patches. You will probably need to make an example of a few developers before the rest catch on; please try to avoid the important people (Linus, Guido, Malcolm etc). The remaining survivors shall call you Sebastian, God of Keeping Open Source Developers Honest. Seriously - Aint no such thing. If you're open sourcing code, you can _hope_ that people contribute back, but no license terms in the world will _compel_ them to do so. All you can do is work on developing a community so that it is obvious that there is a benefit to contributing code back to you. This means setting up a community where end users feel welcome and able to contribute, and feel ownership of the code themselves so that they are encouraged to keep coming back to the community and helping the project to grow. 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: Permissions: is something wrong with them?
On Tue, Jan 6, 2009 at 4:26 AM, Artem Skvira wrote: > On Jan 2, 6:26 pm, Artem Skvira wrote: >> Would anyone be able to comment on the issues raised? > Can I get Russell's comment on that? I'm not entirely sure why I've been flagged personally on this. In addition, it's hard to comment, because it isn't entirely clear why you think "the issues raised" are such a big problem. As best as I can make out, you have two complaints: 1) Defining permissions is too hard 2) Permissions should formally require the For the first point, the method you describe for defining new permissions is one approach. Another approach using model metadata is also described in the documentation [1]. Between the two, I'm not sure why you see the need for helper, especially since permission creation is a once-off activity. As for the second point; the model name isn't required in the permission name, but it isn't prohibited either. This is a matter of convention - including the model name is often a good idea (e.g., the default 'add_X', 'change_X' permissions), but it's easy to think of examples where requiring the model name would be cumbersome (e.g, a 'can_vote' permission on a Citizen model). You are correct that this does open a potential window for an ambiguity where you have two models in the same app with a permission of the same name. I'm not certain about the design decision here (the auth module was written before I joined Django as a core contributor), but I can see how this could be used to allow shared permissions e.g., anyone given permission to open the house gets automatic permission to open the car, and vice versa. Even if this wasn't the design intent, I can't say the problem particularly concerns me. Having a free-form permissions string guided by convention is easy to use, and it has been in use for over 3 years without (to the best of my knowledge) any significant reports of difficulty stemming from the problem you describe. In addition, there is plenty of legacy code using the existing permissions framework that would be onerous to change, and besides - a simple workaround exists: "don't use ambiguous permission names", which is hardly an onerous suggestion. [1] http://docs.djangoproject.com/en/dev/topics/auth/#id1 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: Speeding up the tests, what am I missing?
On Wed, Jan 7, 2009 at 4:51 AM, Todd O'Bryan wrote: > > So, I've been trying to speed up tests. Surprise. I came across a > fairly easy solution, so I'm sure I must be missing something. If > someone could tell me what I'm missing, I'd really appreciate it. ... > MyTestCaseSubclass.dirties_db = True ... > So, what am I missing? I know this doesn't deal with doctests--the db > gets cleaned for all of those, but does anyone see when this is just > going to blow up in my face? This approach will (clearly) speed up tests. I have three objections to the technique. The first objection is a relatively minor syntactical wart. Using a normal assignment to set the dirty bit means your test code is mixing test code with setup code. I'd rather see this sort of thing as a decorator, so that the test i The second objection is more significant: the technique is entirely manual, and prone to error. If you get all the dirties_db markers correct, your tests will be much faster; however, if you get one wrong, you could get all sorts of unexpected consequences, and the problems won't be reported in the test that actually has the incorrect dirty marker. The order in which tests doesn't necessarily match the order in which they are defined in the test case; if you run a subset of tests, all bets on predictable test output are off. The third objection is that in my experience, genuine 0-write test cases aren't actually that common. This will, of course, vary wildly depending on your particular project, but I seem to recall looking at this sort of change and came to the conclusion that it wouldn't actually speed up the Django test suite that much. Feel free to prove me wrong. There are some plans in place to speed up test cases using transactions; I'm hoping to be able to look at this once I put the aggregation and F() code to bed, in the next week or so. 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: Related articles based on keywords.
On Sat, Jan 10, 2009 at 6:27 AM, Ariel Mauricio Nunez Gomez wrote: >>> In the view for a single article, I would like to be able to pull up >>> related articles based on shared keywords. Just pulling up all the >>> articles that share at least one keyword would be to imprecise. What >>> I'd like to do is use some sort of weighting algorithm, so that if >>> there are articles that share 5 keywords they get pulled up while ones >>> that only share 1 do not. I've been thinking over ways to do this, but >>> they all seem to be fairly slow and processor intensive. > > Also, if you are looking for performance, you may want to find a way to use > the SQL aggregation operations (Like Count, Avg, StdDev) to help you with > your problem. > That feature is scheduled for Django 1.1 and 'may' be merged into trunk > soon, It's a little more certain than "may". I have a couple of small issues to attend to, but barring a major bug report, I'd estimate that aggregates will land in trunk by the end of next week. 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: Forcing content_types.json to be loaded before any other fixtures
On Wed, Jan 14, 2009 at 9:34 AM, Giovannetti, Mark wrote: > > Is there a way to force a fixture to be loaded first > when running manage.py test? > > I'd like to load a content_types.json fixture immediately > before any other fixtures are loaded. > > This might fix some of the vexing problems with using > content_types and tests. As far as I can make out, this would fix exactly none of the content type problems. The problem with content types is that content types are dynamically generated, and as a result they are not produced with predictable or consistent key values. As long as you serialize all your content types in your fixture, and you haven't added any new content types since producing the fixture, you shouldn't have any problems deserializing data. > Anyone know if this is possible? No, it isn't possible, and it doesn't really make much sense, either. Fixtures are all loaded in a single database transaction, so the order in which fixtures are loaded doesn't matter. The only exception to this is if you're using InnoDB tables under MySQL, in which case the problem is MySQL's implementation of transactions (specifically, InnoDB doesn't allow deferring of referential integrity checks to the end of the transaction boundary as it should). Of course, it's entirely possible you've found an new class of problem that I wasn't previously aware of, in which case I'd be interested to hear exactly what you've done and how fixture order fixes the problem. 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: writing unit tests for views?
On Tue, Jul 15, 2008 at 8:28 AM, bshaurette <[EMAIL PROTECTED]> wrote: > > Writing tests for models has been a snap, but I'm having a lot harder > time with the views. ... > I'm not new to writing tests, just to unit testing in Django/Python - > what would *really* help is if I could see some other examples of view > testing. I feel like I've been banging my head against a wall for a > few days now. Has anyone got any recommendations? The Django system tests contain a lot of examples of Django view tests. In particular, modeltests/test_client and regressiontests/test_client_regress show how to exercise most of the features of the Django test system. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Unique Case Sensitivity
On Wed, Jul 16, 2008 at 8:59 AM, Chris <[EMAIL PROTECTED]> wrote: > > I've run into a strange situation. I have a MySQL database with a > table called Feature, with a unique column called text. > > Given some text, I want to save a new record if hasn't been entered, > or retrieve the existing record if it already exists. Oddly enough, > this code fails if the current text has already been entered with a > different case (e.g. 'abc' vs 'ABC'). ... > Is this the fault of Django's ORM, or some obscure MySQL setting? I strongly suspect that the problem here is MySQL - in particular, the collation on your text field. There are certain default setups for MySQL which will result in all text fields being case insensitive. This doesn't just affect unique constraints - it affects case sensitive matching as well. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django on Windows Mobile 6 (Standard)
On Thu, Jul 17, 2008 at 7:04 PM, warsng <[EMAIL PROTECTED]> wrote: > > After taking a look at the blogpost where someone got django running > on WM, i thought i would give it a try. however, i am not having much > success. Has anyone got this working recently? I am not using Pocket > PC unlike the blog author, I am using Windows Mobile 6 Standard, i.e. > non-touch-screen. Yes, it can be done; no it isn't easy. The good news is that the problems you will experience aren't Django related - it's a dependency problem. In order to run Django, you need to get Python and SQLite builds for your handheld. Installation binaries for handheld platforms are not easily found, and using the Windows Mobile compiler toolchain to produce installation binaries can be a painful process. Once you have those dependencies compiled, Django works out of the box. The bad news is that it has been a long time since I did this myself, I have almost no recollection what combination of voodoo and black magick was required, and I've changed jobs in the interim, so I can't check a reference build to give you any guidance. However, I assure you it can be done. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Model Inheritance in new-forms admin
On Fri, Jul 18, 2008 at 7:00 PM, cschand <[EMAIL PROTECTED]> wrote: > > When I tried model inheritance in new-forms admin, I faced some > problems ... > What is wrong with me? You haven't checked the tickets: http://code.djangoproject.com/ticket/6755 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Model Inheritance in new-forms admin
On Fri, Jul 18, 2008 at 7:41 PM, cschand <[EMAIL PROTECTED]> wrote: > > Hi Russ >The problem is not solved in the ticket No - that's because it's a bug report. When the bug is fixed, the ticket will be closed. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Must Have Python resources
On Tue, Jul 22, 2008 at 2:21 AM, eka <[EMAIL PROTECTED]> wrote: > > On Jul 21, 6:11 am, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: >> On 21-Jul-08, at 1:53 PM, Hussein B wrote: >> >> > Well, I know this question isn't related to Django but I hope it is ok >> > to ask. >> > What are your favourite Python resources? >> >> diveintopython - and the django book is outdated, better you get > > >> uby's practical django projects > > This is the printed book you are talking about? Let me help out here. The problem appears to be that there is some reluctance to talk in complete sentences, with verbs, subjects, prepositions, punctuation and capitalization. Let's try to do this the right way: "The Django Book", written by Jacob and Adrian, is based on Django 0.96. As such, it's a little out of date. Most of the stuff in this book is still relevant, but there are a few areas (such as the discussions about the admin interface) where it is out of date. James Bennett's "Practical Django Projects" was published quite recently, so it is more up to date. However, due to the rapidly evolving nature of Django at the moment, there will be some minor discrepancies between the book and v1.0. "Dive Into Python" is a good general Python reference. It is available for free online, as well as a 'dead tree' version. It is a little bit old, but Python as a language hasn't changed that much since it was published - there isn't anything in this book that has been deprecated or is likely to confuse. See - that wasn't hard. It takes one message, and it's unambiguous. As a side benefit, the single message works standalone in the archive. Centuries from now, archaeologists will be able to determine what the hell was going on by reading a single message. Please, people - when a thread is turning into dozens of one line replies which reduce to "that isn't what I meant", please consider that maybe TXT SPK might not be the right way to communicate effectively with other professionals. :-) 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Can't Send Password With Test Client
On Tue, Jul 22, 2008 at 5:05 AM, James <[EMAIL PROTECTED]> wrote: > > It appears that the password value isn't printed for security reasons. > The problem remains that the form will not validate. Are you sure you have a test user? Remember, when you run the test suite, you're not using the standard database - you're using a temporary test database which will not contain any users by default. You will need to create a test user before you can log in. Fixtures are one easy way to do this; manually invoking User.objects.create_user() is another. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: email not being sent from within unit tests
On Wed, Aug 20, 2008 at 7:21 AM, Andrew D. Ball <[EMAIL PROTECTED]> wrote: > > I've noticed that email isn't being sent during unit tests > in Django 1.0 beta 1. The django.core.mail.EmailMessage.send > method returns '1' as if it had sent 1 message successfully, > but the SMTP server doesn't get contacted at all. The > same thing happens with django.core.mail.send_mail. > > Is this expected behavior? Is it documented somewhere? Yes, and yes. http://www.djangoproject.com/documentation/testing/#e-mail-services > What gives? I'd like my unit tests to send emails. It's fine > if I have to add a setting or something, but it's not okay that > I'm currently unable to get emails to be sent by unit tests. > > I have a really nice "SMTP black hole" -- an SMTP server on > a VM that delivers mail to any email address to a local mail > spool, so the unit tests' sending emails won't hurt anything. Well... yes it will. It will hurt everyone that doesn't have access to your SMTP black hole, or a black hole of their own (which isn't always going to be easy to set up - for example, on shared hosting). It also means that it isn't easy to check the contents of sent mail as part of your test. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Renaming of mailing lists to avoid user confusion
On Wed, Aug 20, 2008 at 10:59 AM, Mike Scott <[EMAIL PROTECTED]> wrote: > > So the fact that you say we have to force nearly 15000 people to > change is a rather void argument. I'm pretty sure the people who use > django-users mainly do it through the web interface I'd be interested to know how you back up this assertion. The default mode of operation of a Google Group is as a mailing list, and you need to be a member of the group to post. Personally, I almost never use the web interface unless I'm looking for a link to reference a specific message. > - so to them it > would only mean the changing of a web address. Everybodies > subscriptions would stay in tact, they would just have to send to a > slightly different web address. This solves the split archive problem, but it doesn't solve the problem of 3 years of email referring to the 'django-dev' archive. Google groups is good, but it isn't magic. It also doesn't solve the many places that duplicate the django mailing list archives. > There are going to be some initial confusions, yes, but considering it > all I think it'll do more good, than bad. Completely aside from any technical or archival disadvantages, this whole argument hinges on one important assertion: that it is possible to fix this problem with a rename. To this argument I say 'poppycock'. To whit: If we call it django-developers, some users will think "Oh, I'm developing for django, so I'll mail here" If we call it django-internals, some users will think "Oh, I'm developing using the internals of django, so I'll mail here" If we call it django-core (even if it wasn't already taken), some users will think "Oh, I'm using the django core, so I'll mail here". Yes, the current name is ambiguous. So is every other possible name. This is completely aside from the "lazy user" problems, which no rename will solve: * django-developers (or alias) has a smaller readership, so I'm more likely to get an answer * django-developers (or alias) has more experienced developers, so I'm more likely to get an answer * django-developers (or alias) is the first Django mailing list someone found in a search, so they mail without looking for a better forum. So, -1 from me. Russ %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: psycopg2 error with syncdb (but not with sqlite)
On Wed, Aug 20, 2008 at 11:26 AM, Chris Moffitt <[EMAIL PROTECTED]> wrote: > I am seeing this error - http://dpaste.com/72596/ with django trunk (rev > 8445) when I try to run syncdb using psycopg2 but it works just fine if I > use sqlite. > > Basically I'm getting an error when doing the table introspection code. I > can see that there's been some refactoring in this area but the SQL > statements look the same. > > Any thoughts on how best to troubleshoot this? I'm afraid I don't have any magic solutions. The best approach I can suggest is to log the SQL that is being executed (either in the Postgres query log or by putting in some debug statements into Django to output connection.queries). Then narrow down the statement that is causing problems by manually invoking the same SQL line by line until you see the same error. Failing that, providing a minimal database dump that demonstrates the problem may help others to replicate (and possibly solve) the problem. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: another problem with M2M through intermediary
On Wed, Aug 20, 2008 at 12:30 PM, akonsu <[EMAIL PROTECTED]> wrote: > > > consider the code below. it has two print statements at the end. their > output should be identical, but it is not. i think there is a bug. ... > print [p.x for p in Pair.objects.filter(y = y0, name = 'd')] > print y0.xs.filter(pair__name = 'd') I'm pretty certain this is another manifestation of #8046. Looking at the SQL generated, the second case is doing a redundant join, which is resulting in the stray result. I've added a note on that ticket - thanks for the helpful test case. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Noob: form class location
On Sat, Aug 23, 2008 at 8:59 PM, Julien Phalip <[EMAIL PROTECTED]> wrote: > > Hi, > > In Django there are no 'standard' as such. You'd talk more about > 'conventions'. > One common way is to put all your forms in forms.py. But that's just > for cleanliness. While this is a common convention, I would point out that it is not without problems. If you have a local 'forms.py' module, you leave yourself open to name clashes if you use 'from django import forms' in your code. However, the rest of your advice is correct - there is not set rule, just conventions, and as long as Python can import it, the code will work the same regardless of the location. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Testing framework observations
On Tue, Aug 26, 2008 at 11:18 PM, dchandek <[EMAIL PROTECTED]> wrote: > > After several iterations of running tests on an application (manage.py > test myapp), I have these observations which are not really clear in > the documentation: > > 1. All initial_data fixtures (not just those for the tested app) are > always loaded into the test database. Yes, by design. If you don't want this to happen, reconsider whether your data is actually initial data. > 2. Because there is no means to specify fixtures for doctests, you > must have an initial_data fixture to run model doctests against the > test database if existing data is required for the tests. (The > documentation simply says 'Each doctest begins with a "blank slate" — > a fresh database containing an empty table for each model.') That documentation isn't completely correct - it needs to be slightly reworded. doctests do no special setup - that means they inherit whatever database conditions are present when they execute. If there is only 1 doctest, this means a clean test database with initial data loaded; if there are other tests, there could be leftover detritus from other tests. However, regarding fixtures in doctests: See #5624 and #8138. > 3. Loading specific fixtures in django.test.TestCase instances is not > echoed to stdout. (The documentation is clear that the test database > is flushed before each test.) Why should they be echoed? If you have 200 tests, you don't want 200 lines to output saying "loaded fixture X". Your test declares the fixture that has been loaded; you only get output (and error output at that) if the fixture fails to load. > 4. django.test.TestCase effectively reloads initial_data fixtures with > every test because it calls the flush command. Again, by design. Why shouldn't it? 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: ManyToMany + through + using add, d
On Fri, Aug 29, 2008 at 8:09 PM, Richard Ward <[EMAIL PROTECTED]> wrote: > > It looks like the solution to this is in the newest release. Ref. > http://code.djangoproject.com/changeset/8136 Richard - Gergo, Antti, and I are well aware of the m2m intermediate change in [8136]. What we are discussing here is a possible extension to allow use of the add() in m2m relations that have a through clause. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Schema Evolution Choices?
On Tue, Sep 2, 2008 at 12:37 AM, Jon Loyens <[EMAIL PROTECTED]> wrote: > > Hi guys, > > I have a small project coming up that I think having some sort of > schema evolution facilities will be handy on. I was wondering what > the current and best project choices for schema evolution are? I was > leaning towards django-evolution until I saw a post from Russell > saying that he hadn't updated it to the 1.0 branch yet. The key word here is _yet_. I'm expecting to do this update in the very near future, by which I mean "probably within a week". In the meantime, there are a number of patches in the django-evolution ticket repository that will fix many of the problems that have been caused by the recent changes to Django. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Discover tests in forms.py
On Thu, Sep 4, 2008 at 11:13 PM, Peter Bengtsson <[EMAIL PROTECTED]> wrote: > > From http://www.djangoproject.com/documentation/testing/ > "4. Looking for unit tests and doctests in the models.py and tests.py > files in each installed application." > > Next to models.py I have forms.py which does exactly what the filename > suggests: it defines forms. I've put some doctests in these classes. > How do I get the testrunner to discover them? Hi Peter, The short answer is "it wont". The default test runner only looks in models.py and tests.py. However, if you want to put your tests somewhere else (such as in forms.py), you can define your own test runner which implements its own test discovery strategy. This is documented: http://docs.djangoproject.com/en/dev/topics/testing/#using-different-testing-frameworks If your looking for an example to follow, the code for django.test.simple isn't too hard to tear apart and customize for your own purposes. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django on non relational DBs
On Sat, Sep 6, 2008 at 10:03 AM, Posi <[EMAIL PROTECTED]> wrote: > > Now that 1.0 was released, how hard or desirable would it be to > consider column based DBs like HBase, hypertable, etc for Django > backends? Desirable - certainly. Hard - yes. This isn't going to be a simple 'just implement the PEP' job - there will be some complex issues to resolve. It's not a job for a novice. > Currently the model behavior seems tightly coupled to > traditional DB models, is this really what we want? This isn't entirely true. If you dig into the ORM refactor, a lot of the effort involved was centered around breaking the SQL specific parts into django.db.models.query into django.db.models.query.sql. This means we have, in principle, separation of concerns between SQL-specific and ORM-specific parts. In practice, we don't have any other backed, so it's difficult to validate that the interface is completely decoupled or that the interface provided is completely suitable. Clarifying and resolving these sorts of issues would be one of the the major tasks for developing a non-SQL backend. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Ordering by ManyToManyField length
On Sun, Sep 7, 2008 at 1:04 PM, Jarred Bishop <[EMAIL PROTECTED]> wrote:
>
> Hello. How would I do this?
>
> Say I have a model 'Tag' that has a ManyToManyField called 'entries',
> can I order a query by total entries?
>
> something like this is how I imagine it would work:
> Tag.objects.all().order_by("entries.count") but I cannot find a proper
> example.
At the moment, Django doesn't have any support for aggregates except
for very simple counts, so doing anything by count on a related table
will not be possible. However, adding aggregates is on the list for
the next version of Django - the patch has been written (#3566), it
just needs some final review and a commit.
I don't think there is a test case for your specific example, but it
should be possible using a query something like:
Tag.objects.annotate(entry_count=Count(entries)).order_by('entry_count').
I'll make sure an example like yours is in the final test suite.
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Django Evolution
On Tue, Sep 9, 2008 at 6:25 PM, Greig Rapley <[EMAIL PROTECTED]> wrote: > > After upgrading to Django 1.0 I am having trouble getting django > evolution (svn) to work. I have looked on their site, and applied one > of the patches made available (for ImageField), but still no luck. I > found a post dated September 2 from Keith saying he would update the > project within a week, so I understand things will be upgraded > shortly. Firstly, I presume you're talking about me - Russell. I have no idea who Keith is. Secondly, this is probably a question better suited to the Django Evolution mailing list. However, that said: I have updated Django Evolution to be compatible with Django v1.0. However, as you have noted, there is a problem with ImageField (and FileField) migrations if you have a project that was using Django Evolution prior to r8244, updating Django Evolution will cause some problems. Ticket #72 on the Django Evolution repository [1] contains a patch that can be used as a workaround. This should get you over the hump you are currently stuck on. I haven't applied this patch because I am trying to avoid hard coding the eccentricities of individual Django revisions into the Evolution core itself; however, in conversations I had with Christian Hammond during Djangocon, it became apparent that this may not be an achievable goal. The longer term goal is to provide a baked-in way to overcome these changes in Django itself. > My question is, can I remove django_evolution from settings.py, apply > the change I need right now manually, and then when django evolution > is running happily against 1.0, somehow baseline and start again ? > Should I delete the django_evolution table from the database before re- > enabling django_evolution in settings.py ? I don't mind losing the > migration history and starting again, I just want to know that if I go > manual updates for now, I can somehow re-baseline or start again, > because I find it very useful. The re-baseline command is the subject of ticket #65 [2]. It is fairly high on my list of Django Evolution priorities; I just need to get some downtime to work on it (or, alternatively, if it is important to you, submit a patch and it will get priority inclusion). I haven't tried your 'manual rebaselining' approaches, but my gut reaction is that it should work. Dropping the tables themselves means that any historical signatures (such as the signature that is currently causing difficulty) will also be removed. If you don't care about losing history, simply dropping the existing evolution tables should be sufficient to reset the evolution chains using new signatures. At the time you run syncdb, all the historical stored evolutions will be marked as applied. [1] http://code.google.com/p/django-evolution/issues/detail?id=72 [2] http://code.google.com/p/django-evolution/issues/detail?id=65 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Creating an Archive
On Wed, Sep 10, 2008 at 4:31 AM, djandrow <[EMAIL PROTECTED]> wrote:
> I just get 2008-01-01, i guess thats cos I only have entries in 2008
> and the date is formatted wrongly, so my question is how can i get a
> list of months, like you find on any archive links; September 2008,
> October 2008 etc.
Well - the template is printing exactly what you asked it to. You give
it a list of all dates where you have entries, and it prints a single
date - in the default format.
If you want a different list of dates to be printed, then you will
need to pass that list into your view so your template can iterate
over it. Make sure you handle the case where no entries are available,
either by not rendering those dates as links, or making sure that you
have the empty case handled on the view.
As for formatting the date, Django provides filters that can do this:
http://docs.djangoproject.com/en/dev/ref/templates/builtins/#date
> 2. At the moment i've just been testing the generic view in a template
> which does nothing else apart from show archive links, how can I
> incorporate this with my main template (the index page I already have)
> which uses views?
The same way you incorporate any other piece of a Django template -
using {% extends %}
http://docs.djangoproject.com/en/dev/ref/templates/builtins/#extends
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: TestClient with no Django Database
On Fri, Sep 12, 2008 at 7:35 AM, Denali Lumma <[EMAIL PROTECTED]> wrote: > > Hi There, > > I am trying to use the TestClient class to validate some of our > pages. It seems to work OK for pages which don't require > authentication. It should work fine for pages _with_ authentication, too; you just need to authenticate the client first. > I am aware of the test database which is created and used in the > TestClient run, however, we have a special set up here. We are not > using any of Django's database support code. We have our own lower > level code which interacts with the database. You appear to be getting some terminology confused here. Are you talking about: * the TestClient - the dummy web browser * the Django Test Case - a wrapper around unittest.TestCase that provides a TestClient instance * the Django Test Runner - which creates the test database. The TestClient itself doesn't do anything with the database connection. It just hits the URLconf to activate the requested views and get the response. You should be able to run the TestClient without ever touching the database backend code. However, if you're talking about the test runner, the solution is easy - write a custom test runner. If you want to use an existing database rather than the Django Test database, take a copy of the runtests method in django.test.simple, remove the parts that create and destroy the test database, and refer to your modified version in the TEST_RUNNNER value of your settings file. See here for more details on the general process: http://docs.djangoproject.com/en/dev/topics/testing/#using-different-testing-frameworks 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Displaying a list of lists?
On Fri, Sep 12, 2008 at 2:36 AM, Lance F. Squire <[EMAIL PROTECTED]> wrote:
>
> Currently using Django version 0.96.3, on a Fedora 8 system.
>
> I've currently set-up models for 'Manufacturer' and 'System'. System
> has a Foreignkey to Manufacturer.
>
> I'd like to display a list like so:
>
> Manu A
> System a
> System b
> System c
>
> Manu B
> System a
> System b
> System c
>
> Etc...
>
> Only listing Manufacturers that had systems of type X.
>
> I was thinking of using code like this in the View,
>
> man=Manufacturer.objects.all()
for m in man:
> ...sys=System.objects.filter(manufacturer=m.id)
> ...print m.name
> ...for s in sys:
> ... print " %s" % s.name
> ...
>
> This works from the shell, but I'm unsure how to get the output to the
> template And, I suspect is a terribly inefficient way to do it anyway.
Sounds like you're looking for something like the following:
{% for m in man %}
{{ m.name }}
{% for s in m.sys_set.all %}
{{ s.name }}
{% endfor %}
{% endfor %}
(plus some formatting bits, but they should be pretty obvious). This
assumes that "man" is in your context, and contains a list of
manufacturers (Manufacturer.objects.all(), for instance). The only
piece of this puzzle that might be a little confusing is
'm.sys_set.all'. m.sys_set is Django's way of saying "get all the sys
objects that are related to the Manufacturer m". More details here:
http://docs.djangoproject.com/en/dev/topics/db/queries/#following-relationships-backward
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: ORM vs SQL vs HBase
On Sun, Sep 14, 2008 at 7:24 AM, Martin Diers <[EMAIL PROTECTED]> wrote: > > On Sep 6, 2008, at 11:36 AM, Posi wrote: >> >> Still though, how tied are we to a true relational model and how does >> that tie to a column based DB. > > So utterly and completely, that if you wished to use HBase, there > would be no possible way to integrate in into the current ORM. This answer is utterly and completely untrue. One of the outcomes of the recent queryset-refactor was to decouple the SQL specific parts of the ORM from the queryset itself. Writing a non-SQL backend for queries is now in the realm of possibility (and during DjangoCon, I heard at least one mention of a prototype CouchDB backend). Obviously, there will always be limitations - the concept of 'joins' on CouchDB is a little vague, for example - but basic data queries can definitely be integrated. To be clear - this doesn't mean "writing a CouchDB backed is a 30 minute job for a newcomer", and there aren't any tutorials on how to do this, and if you try and it breaks you get to keep every single one of the shiny pieces. However, it is _possible_, and I for one am interested in seeing support for non-SQL databases in the Django world. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: maxlength or max_length?
On Sun, Sep 14, 2008 at 8:31 PM, djandrow <[EMAIL PROTECTED]> wrote: > > I'm currently using django Version: 1.0-final-SVN-9020 and python > Version: 2.4.4, a few weeks ago (maybe a bit longer) I had to change > all my maxlengths to max_length, as I believe that was a change in > Django. > > Anyway now when i try and use manage.py validate I get: > > __init__() got an unexpected keyword argument 'max_length' > > however if i call parts of the model from the templates they work > fine. > > So my question is what is going on? and what should i be using? max_length is definitely the correct version. If you are getting errors, you either have an old version of Django in your PYTHONPATH, or the error that is being thrown by something other than a field validation. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: working with yaml fixtures
On Mon, Sep 15, 2008 at 10:27 AM, sotirac <[EMAIL PROTECTED]> wrote: > > I'm trying to initialize my database using yaml fixtures. > I've created a yaml fixtures directory (src/fixtures). Within the > yaml fixtures directory, I created a yaml fixtures file title > websites.yaml. ... > Now when I try to invoke the command "python > manage.py loaddata fixtures/websites" inside my src directory, it > gives me no error message but nothing is added into my sqlite > database. You say you didn't get an error message, but did you get a message saying "X objects loaded from Y fixtures"? If you didn't see this message, then the fixtures have not been loaded. The next thing to check is where you have put the fixtures. You say you put the fixtures in a src/fixtures directory - did you add this directory in the FIXTURE_DIRS setting? By default, Django will only look for a fixtures directory in each installed applicaiton (e.g., if you have polls/models.py, Django will look in polls/fixtures/* for fixtures). If you want to use another directory, you will need to register that directory using the FIXTURE_DIRS setting. Lastly, you only need to specify the fixture name when loading the fixture (i.e., "websites" or "websites.yaml") - you don't need to provide a full path for the fixture. Django will fill in the rest of the path name as it searches the known locations for fixtures. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Get times of day with most entries
On Mon, Sep 15, 2008 at 8:33 PM, Henrik Lied <[EMAIL PROTECTED]> wrote: > > Hi there! > > I'm working on a very interesting pet project where I monitor the > traffic outside a house. ... > This adds up to quite a lot of traffic in a day, and I want to be able > to filter out which time of day the traffic is at it's highest. > > Is there a good way of doing this? There are actually 2 problems here: 1) How do you intend to reduce a point sampling into a 'traffic volume' statistic? 2) How do you extract that statistic from the database? The first question is better suited for your stats professor rather than this group. A simple solution would be a moving window count; however, you then need to pick an appropriate window size and establish if the resulting summary has the statistical properties you desire. The second question is the Django question. Unfortunately, right now, the answer is "not easily". Django doesn't currently have support for aggregation functions (averaging, non-trivial counting etc). This should be fixed in the very near future - a patch adding aggregation functions was implemented as part of the Google Summer of Code, and this patch should be integrated into Django for the v1.1 release in about 6 months time. In the interim, your only option is to use custom SQL. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: 1.0 branch
On Tue, Sep 16, 2008 at 1:53 AM, Steve Holden <[EMAIL PROTECTED]> wrote: > > J. Pablo Fernández wrote: >> Hello, >> >> Which one is the 1.0 branch on the SVN repo? >> >> Thanks. >> >> > Erm, that would be the one tagged "1.0" I guess. But I haven't actually > checked, because the best way to get 1.0 is to download it from Sounds like it's time to brush up on your SVN nomenclature, Steve :-) A Tag is an immutable reflection of a point in time in the development process. A Branch is a copy of a body of code at a point in time that can be modified independent of the original version. Now, it gets hazy because SVN implements both Tags and Branches as copies, so the only thing stopping you from modifying the code in a Tag is convention. However, Django intends to honor that convention. Django has tagged v1.0. At some point in the very near future, we will create a v1.0.X branch. The reason for deferring the creation of a branch is that once we have branched, bugs need to be fixed in two placed - both trunk and branch. This is a pain to manage, so for a week or two after the release, we will refrain from adding features and just fix bugs (at the moment, mostly documentation bugs). So - the answer to the original question is "There isn't a 1.0 branch yet, but there will be very soon". 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Is this group censored, or is the archive just buggy?
On Tue, Sep 16, 2008 at 4:10 AM, catsclaw <[EMAIL PROTECTED]> wrote: > > Hi -- > > I've been having major problems with the url configurations, and I > posted a summary of the problems on this list last night. I received > a reply, and responded to that. Now, however, the list has no record > of the conversation. Was it intentionally deleted by a moderator, or > should I just repost it? > If it was removed by a moderator, where are the posting guidelines? With the obvious exception of spam, this list is uncensored. If it makes you feel any better, I have found that Google Groups search to be particularly unreliable, even when you can give it a specific phrase that you know are in the message you are trying to find. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: manage.py reset auth fails
On Tue, Sep 16, 2008 at 11:03 AM, akonsu <[EMAIL PROTECTED]> wrote: > > hello, > > on pgsql 'reset auth' fails with an error saying that it cannot drop > one of the tables (i do not remember which though) because other > objects depend on it. on sqlite it works fine. i did not try it on > mysql. This isn't surprising. Postgres has referential integrity. SQLite doesn't have any referential integrity. MySQL only has referential integrity if you're using InnoDB tables. The reset command is problematic when you have referential integrity, because you can have all sorts of circular dependencies in your data which the constraints can trip over. It isn't a problem that can be easily fixed, either. Untangling the web of potential constraints is a hard problem. As a result of these complications, I've long been an advocate for removing the reset command entirely. However, this isn't really feasible until there is a comprehensive schema evolution solution available. The discussions that happened at DjangoCon lead me to believe that we're not that far off this becoming a reality. If you're looking to do a cleanup of your database, you may find that flush is a better option. This operates on an entire database rather than a single application, but if you're looking to delete all your tables and start fresh, it will always work. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Many-To-Many with extra fields
On Sat, Sep 20, 2008 at 8:37 AM, Nate Thelen <[EMAIL PROTECTED]> wrote:
>
> Looking at the docs here:
>
> http://docs.djangoproject.com/en/dev/topics/db/models/#extra-fields-on-many-to-many-relationships
>
> I cannot find any reference to how to access the data in the
> "Membership" table. For example, if I have a reference to the
> "beatles" object, how do I find the "date_joined" for each of the
> "Person" objects. I have looked through the other sections of the
> documentation, searched this group, and searched via Google, but
> couldn't find the info.
Short version: You access the membership table using the foreign key
relationship that the membership defines.
Long version: Your question ("the date_joined for each person object")
is actually ill posed - a person doesn't have a date_joined without a
group to also give context. "The date person X joined group Y" can be
answered as:
>>> Membership.objects.get(person=X, group=y).date_joined
It might help to think about it like this - m2m-intermediate tables
don't add extra data to an m2m relation, they make a 2-step foreign
key relation behave like an m2m relation.
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
