Re: How to execute some user defined codes (functions) when Django boot?
Seems to me that "on boot up" doesn't mean anything in a shared- nothing architecture like Django's. For example if you deploy on eg. mod_wsgi. You have no idea how long any particular thread or process is going to live, and no idea how often this "boot" code would get run. But assuming that's OK, one naive strategy would be to just call the function(s) at top level in some module that gets imported by your app. Good enough? On Aug 17, 9:12 am, Mathieu Leduc-Hamel wrote: > Tang, > > do you mean : > > "How to execute some pieces of code when you launch the "runserver" command > by example" ? If this is what you mean, it's not a easy thing to do right > now. Then only way i found it possible is by using: twod.wsgi > > With twod.wsgi you can use the entry points system of python and do, like in > Pylons, an entry defined by Paster "app_factory" > > You can see an example > there:http://packages.python.org/twod.wsgi/manual/paste-factory.html#using-... > > mathieu > > On Tue, Aug 17, 2010 at 2:45 PM, Emily Rodgers > > wrote: > > On Aug 17, 2:26 am, Tang Daogang wrote: > > > Dear all, > > > > Recently, I have developed a plugin system for my app, and I want to > > > register those plugins when my app boot up, this need to execute some > > > user defined codes (functions) in app boot procedure, I don't know > > > where insert my registering codes to, anyone can help? > > > > Thank you. > > > Hi, > > > I don't know how to help you, but I think it is because you haven't > > explained what you want to do thoroughly enough. > > > What do you mean by a plugin system, and what do you mean by > > registering them with the app on boot up? Are you talking about > > including another python module in your code? Or perhaps including > > another django app in your code? > > > Can you give us a bit more information (and maybe examples) of what > > you are trying to do. > > > Cheers, > > Em > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django users" group. > > To post to this group, send email to django-us...@googlegroups.com. > > To unsubscribe from this group, send email to > > django-users+unsubscr...@googlegroups.com > > . > > For more options, visit this group at > >http://groups.google.com/group/django-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
what to do instead of adding to Query.extra_where ?
Hi folks,
I'm working on a codebase (a fork of http://code.google.com/p/ebcode/)
that is supposed to be run against Django 1.1. It has several lines
like this:
clone.query.extra_where += ('db_newsitem.id =
db_attribute.news_item_id',)
That line raises a traceback like this:
Traceback (most recent call last):
File "./everyblock/everyblock/cities/boston/building_permits/
retrieval.py", line 90, in
PermitScraper().update()
File "/home/pw/builds/openblock/builds/20100824/ebdata/ebdata/
retrieval/scrapers/newsitem_list_detail.py", line 208, in update
super(NewsItemListDetailScraper, self).update()
File "/home/pw/builds/openblock/builds/20100824/ebdata/ebdata/
retrieval/scrapers/list_detail.py", line 112, in update
self.update_from_string(page)
File "/home/pw/builds/openblock/builds/20100824/ebdata/ebdata/
retrieval/scrapers/list_detail.py", line 140, in update_from_string
old_record = self.existing_record(list_record)
File "./everyblock/everyblock/cities/boston/building_permits/
retrieval.py", line 65, in existing_record
qs = qs.by_attribute(self.schema_fields['raw_address'],
record['address'])
File "/home/pw/builds/openblock/builds/20100824/ebpub/ebpub/db/
models.py", line 317, in by_attribute
clone = self.prepare_attribute_qs()
File "/home/pw/builds/openblock/builds/20100824/ebpub/ebpub/db/
models.py", line 300, in prepare_attribute_qs
clone.query.extra_where += ('db_newsitem.id =
db_attribute.news_item_id',)
AttributeError: 'GeoQuery' object has no attribute 'extra_where'
For more context, the relevant models.py code is at
http://github.com/openplans/openblock/blob/master/ebpub/ebpub/db/models.py
and `clone.query` is an instance of
django.contrib.gis.db.models.sql.query.GeoQuery, which inherits from
the usual BaseQuery.
Now, I've found by googling and downloading old releases that
django.db.models.sql.query.BaseQuery had an extra_where attribute as
of Django 1.0, but it's gone in Django 1.1.
And from looking at recent and old versions of the docs, I don't think
that extra_where was ever really part of the API; you're probably not
supposed to twiddle it directly.
I haven't yet found a documented way to solve this.
http://docs.djangoproject.com/en/dev/ref/models/querysets/ talks about
the .extra(where=...) method,
but that's part of the manager API and the QuerySet API, not the Query
API.
The one thing I've found, by poking around in the django source, is to
call clone.query.where.add(ExtraWhere(...)) but it's not clear to me
whether that's really part of the API either. Is there a better /
"correct" way?
Thanks,
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: what to do instead of adding to Query.extra_where ?
Hah. That was a pretty long message relative to how quickly I found
the answer myself :-p
Sorry for the noise.
For posterity, extra(where=...) is indeed the solution. I overlooked
the obvious:
the class I was trying to fix is itself a subclass of QuerySet. So
given this line:
clone.query.extra_where += ('db_newsitem.id =
db_attribute.news_item_id',)
the replacement is now:
clone = clone.extra(where=('db_newsitem.id =
db_attribute.news_item_id',))
Seems to work fine.
On Sep 1, 11:41 pm, Paul Winkler wrote:
> Hi folks,
>
> I'm working on a codebase (a fork ofhttp://code.google.com/p/ebcode/)
> that is supposed to be run against Django 1.1. It has several lines
> like this:
>
> clone.query.extra_where += ('db_newsitem.id =
> db_attribute.news_item_id',)
>
> That line raises a traceback like this:
>
> Traceback (most recent call last):
> File "./everyblock/everyblock/cities/boston/building_permits/
> retrieval.py", line 90, in
> PermitScraper().update()
> File "/home/pw/builds/openblock/builds/20100824/ebdata/ebdata/
> retrieval/scrapers/newsitem_list_detail.py", line 208, in update
> super(NewsItemListDetailScraper, self).update()
> File "/home/pw/builds/openblock/builds/20100824/ebdata/ebdata/
> retrieval/scrapers/list_detail.py", line 112, in update
> self.update_from_string(page)
> File "/home/pw/builds/openblock/builds/20100824/ebdata/ebdata/
> retrieval/scrapers/list_detail.py", line 140, in update_from_string
> old_record = self.existing_record(list_record)
> File "./everyblock/everyblock/cities/boston/building_permits/
> retrieval.py", line 65, in existing_record
> qs = qs.by_attribute(self.schema_fields['raw_address'],
> record['address'])
> File "/home/pw/builds/openblock/builds/20100824/ebpub/ebpub/db/
> models.py", line 317, in by_attribute
> clone = self.prepare_attribute_qs()
> File "/home/pw/builds/openblock/builds/20100824/ebpub/ebpub/db/
> models.py", line 300, in prepare_attribute_qs
> clone.query.extra_where += ('db_newsitem.id =
> db_attribute.news_item_id',)
> AttributeError: 'GeoQuery' object has no attribute 'extra_where'
>
> For more context, the relevant models.py code is
> athttp://github.com/openplans/openblock/blob/master/ebpub/ebpub/db/mode...
> and `clone.query` is an instance of
> django.contrib.gis.db.models.sql.query.GeoQuery, which inherits from
> the usual BaseQuery.
>
> Now, I've found by googling and downloading old releases that
> django.db.models.sql.query.BaseQuery had an extra_where attribute as
> of Django 1.0, but it's gone in Django 1.1.
> And from looking at recent and old versions of the docs, I don't think
> that extra_where was ever really part of the API; you're probably not
> supposed to twiddle it directly.
>
> I haven't yet found a documented way to solve
> this.http://docs.djangoproject.com/en/dev/ref/models/querysets/talks about
> the .extra(where=...) method,
> but that's part of the manager API and the QuerySet API, not the Query
> API.
>
> The one thing I've found, by poking around in the django source, is to
> call clone.query.where.add(ExtraWhere(...)) but it's not clear to me
> whether that's really part of the API either. Is there a better /
> "correct" way?
>
> Thanks,
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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: Unit testing in django without using test client
On Sep 16, 10:11 am, girish shabadimath wrote: > thanks for reply, > actually i used unit test to test urls and other view functions,,,there is a > module called Client() in django which acts as a browser to test urls,,, > > my problem is ,i want to test other methods in my project,,, how to do > so, without making use of django's test client..?.. Exactly the same way you test any other python code. What's the problem? -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: Launching Background Processes from a View
On Sep 16, 10:11 am, Heath wrote: > My eventual solution was to just rework the way my watcher scripts > execute. I now use celery and rabbitMQ, and let pyInotify send a new > job to any available worker. For my application, 20 or so workers is > fine and this can scale as needed. > > I'm still looking for a definitive answer on whether the built-in > process > modules cannot launch and detach a process in the background, (ala > "nohup &" ) and return control to the view. Sure they can. Check the docs for the subprocess module, specifically the P_NOWAIT example. - PW -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: Unit testing in django without using test client
On Fri, Sep 17, 2010 at 10:58:19AM +0530, girish shabadimath wrote: > hi Paul, > > thanks for d reply,,,but im new to python n django,,,dint do ne python unit > testing before,,can u plz give me some links or hints to start with... http://docs.djangoproject.com/en/1.2/topics/testing/ has plenty of examples, many without using django.test.client. -- Paul Winkler http://www.slinkp.com -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: Unit testing in django without using test client
On Fri, Sep 17, 2010 at 10:58:19AM +0530, girish shabadimath wrote: > hi Paul, > > thanks for d reply,,,but im new to python n django,,,dint do ne python unit > testing before,,can u plz give me some links or hints to start with... http://docs.djangoproject.com/en/1.2/topics/testing/ has plenty of examples, many without using django.test.client. -- Paul Winkler http://www.slinkp.com -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: output shapefiles
If you're using PostGIS, one option might be to call its dumper as a
separate process.
http://postgis.refractions.net/docs/ch04.html#id2638528
Don't know what tools exist for other spatial databases...
On Oct 12, 1:50 am, Evan Bowling wrote:
> Hello all!
>
> I was wondering if anyone knew if there was a way to output a
> shapefile from a django database. I didn't find anything in previous
> posts, and couldn't figure anything out just yet looking at django/
> contrib/gis/gdal/datasource.py
>
> I was hoping I could do something like the following:
>
> >>> import os
> >>> from geodjango import world
> >>> world_shp = os.path.abspath(os.path.join(os.path.dirname(world.__file__),
>
> ... 'data/TM_WORLD_BORDERS-0.3.shp'))
>
> >>> from django.contrib.gis.gdal import *
> >>> ds = DataSource(world_shp)
> >>> ds.save('data/TM_WORLD_BORDERS-0.3_new.shp')
>
> I'm working on creating an application where users can create their
> own dataset using OpenLayers or Google Maps, and I would like to
> create an option to export the data in a shapefile format.
>
> Thanks,
> Evan
>
> I am Django (and so can you!)
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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: HTTP load testing tools?
On Oct 13, 4:17 am, Chris Withers wrote: > Hey all, > > I hope this is still on topic, but what tool sets do people around here > use for doing load testing of Django projects? Same stuff as for any web project. Last time I needed something more than ab, I used funkload (it's on pypi). A bit of work to set it up, but being able to record browser sessions as test cases is handy, and the report documents it produces are pretty nice ... if a bit overly verbose for my taste. - PW -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: HTTP load testing tools?
On Oct 13, 10:27 am, Paul Winkler wrote: > On Oct 13, 4:17 am, Chris Withers wrote: > > > Hey all, > > > I hope this is still on topic, but what tool sets do people around here > > use for doingloadtestingof Django projects? > > Same stuff as for any web project. Last time I needed something more > than ab, I used funkload (it's on pypi). A bit of work to set it up, > but being able to record browser sessions as test cases is handy, and > the report documents it produces are pretty nice ... if a bit overly > verbose for my taste. Relatedly, I just came across Benchmaster, which wraps Funkload so you can run it in parallel on lots of clients. http://pypi.python.org/pypi/benchmaster - PW -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: call more than one view action from an uri path?
On Oct 21, 10:39 am, Steve Holden wrote: > REST, however, has a fairly rigid one-URL-one-action structure Obligatory REST nitpick: REST maps URIs to resources, not actions. In HTTP, the HTTP methods specify the action to perform. (REST as described by Fielding also has nothing whatsoever to say about what URIs should look like, but nice URIs and widespread URL conventions are so helpful to humans that nobody cares what he says ;-) ... unfortunately this also leads people to completely ignore what he says about hypertext.) - PW -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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.
Fixtures with deferred / auto-generated primary keys?
It would sometimes be useful to be able to write fixtures that essentially say "I don't care what the PK of this record is, as long as I have a way for other records in this fixture to refer to it." Use case: I'd like a way to pass around useful data sets that people can load into deployments of my app. A user could choose to load any of these in any combination, possibly combined with data created by any other means, eg. the admin UI. But this means there's no safe way to know what the PKs should be - unless we use UUIDs for ids, which I'd really rather not do (uuid.uuid4().int is too big to fit into an integer id; changing all my apps to use varchar IDs would be a huge pain, and I assume would be less efficient.) (Another possible wrinkle is that each fixture file should not refer to records not contained in that fixture; I think that could reasonably fall into the category of "just don't do that". Not sure.) I found an old discussion which suggests a possible solution to explore, inspired by Rails: http://groups.google.com/group/django-users/browse_frm/thread/5fb1d260f69a2a9f/e047e049d366b3c1?lnk=gst&q=loaddata+primary#e047e049d366b3c1 ... but the thread quickly degenerated and fizzled, so I'm guessing nothing ever came of this. Anybody know otherwise? The Rails approach looks pretty sensible to me - essentially it just means supporting a variation of the fixture format, which I would think could be easily detect at load time: http://api.rubyonrails.org/classes/Fixtures.html Ideally there'd be a dumpdata option to write out PK-less fixtures, but that could come later - I think just supporting this feature in loaddata for hand-written fixtures would be useful as a first step. I have no idea yet how easy it would be to write this, just wondering at this stage if anybody had already written something to solve this problem :) - PW -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: Fixtures with deferred / auto-generated primary keys?
Thanks Shawn! That was quick! Meanwhile I just discovered http://farmdev.com/projects/fixture which I have just confirmed works fine for hand-written fixtures with my app, although using python classes as fixtures feels a little odd. Nice that it's cross-platform though, it supports sqlalchemy and sqlobject and appengine as well as django. It looks like using Django 1.2's built-in natural keys support will be a lot less work in many situations, since Fixture doesn't (yet) have support for dumping existing Django data to a file. Going to try natural keys! - PW On Oct 22, 11:56 am, Shawn Milochik wrote: > And like magic, it's there! > > http://docs.djangoproject.com/en/dev/topics/serialization/#natural-keys -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: Fixtures with deferred / auto-generated primary keys?
Tried it out. Interestingly, natural keys are currently used only for foreign key references, the dump still contains primary keys. Looks like there's a patch for leaving out PK's when natural keys are used: http://code.djangoproject.com/ticket/13252 That would get me 100% of the way there. - PW On Oct 22, 12:38 pm, Paul Winkler wrote: > Thanks Shawn! That was quick! > > Meanwhile I just discoveredhttp://farmdev.com/projects/fixturewhich > I have just confirmed works fine for hand-written fixtures with my > app, although using python classes as fixtures feels a little odd. > Nice that it's cross-platform though, it supports sqlalchemy and > sqlobject and appengine as well as django. > > It looks like using Django 1.2's built-in natural keys support will be > a lot less work in many situations, since Fixture doesn't (yet) have > support for dumping existing Django data to a file. > Going to try natural keys! > > - PW > > On Oct 22, 11:56 am, Shawn Milochik wrote: > > > And like magic, it's there! > > >http://docs.djangoproject.com/en/dev/topics/serialization/#natural-keys > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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.
Overriding the JOIN type in contrib.admin's search forms?
Bear with me, I'm a Django novice, still reading docs...
I'm trying to build my first app using django admin (release 0.96),
because it's a good match to the requirements (a quick and simple CRUD
application).
I found a thread from last year
http://groups.google.com/group/django-users/browse_thread/thread/b0866749612aaeae/135d13ce40c33aa7?lnk=gst&q=admin+search_fields+join#135d13ce40c33aa7
where the last post describes the same problem I'm having, but there
were no further replies.
All was coming along nicely until I started using 'the lookup API
“follow” notation' to get a foreign key into my search_fields, like
this:
class FilmClip(models.Model):
...
class Admin:
...
search_fields = ('clip_id', 'label', 'description',
'filmcliplog__description' # This is the
line that causes problems
)
class FilmClipLog(models.Model):
clip = models.ForeignKey(FilmClip,
edit_inline=models.TABULAR,
num_in_admin=3)
...
There are two problems with the resulting behavior:
1) Any matching FilmClip thas has at least one FilmClipLog will show
up in the results twice.
2) Any matching FilmClip that has no FilmClipLogs will not show up at
all.
From the mysql query log, I've found that the query looks like:
SELECT ... FROM `filmy_filmclip` INNER JOIN `filmy_filmcliplog` ...
But what I want is this:
SELECT DISTINCT ... FROM `filmy_filmclip` LEFT OUTER JOIN
`filmy_filmcliplog` ...
So, my questions:
1) Is this a Django bug? When would the existing behavior be
desirable?
2) Is there a way to specify the type of join in the search query?
3) Is there a way to add DISTINCT to the search query?
4) If no, what's the quickest way to get the behavior I want?
Thanks,
- PW
--~--~-~--~~~---~--~~
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: unit testing and comparing dictionaries
On Jun 17, 1:46 am, "Gene Campbell" <[EMAIL PROTECTED]> wrote: > Hello Djangonauts > > I'm a noob on both Django and Python, so this question might be easy > for the experts out there. I am trying to do test first development > during the development of my model code. (I have lots of experience > with test first coding in the Java world, no practical experience in > the Py world.) > > I want to do something like this > > class ModelTest(TestCase): > > def test_crud_modelone(self): > mo = ModelOne( name="A name" ) > mo.save() > > saved_mo = mo.objects.get(pk=mo.id) > > assertEqual( vars(mo), vars(saved_mo),"Something not getting saved") > > That assertEqual line fails. I wrote this You didn't say what exactly happens. If it's failing with a NameError, notice that you forgot to specify self.assertEqual(). There's no implicit "this" like in Java. And as others have mentioned, vars() is rarely used in practice. And if there's a problem, it'll be hard to see what's wrong. It's more tedious but ultimately more helpful to specify everything: self.assertEqual(mo.foo, saved_mo.foo) self.assertEqual(mo.bar, saved_mo.bar) ... and so forth. Also, as a fellow django noob I'm not sure about this, but I seem to recall that mo and saved_mo should be exactly the same object? If that's true (hopefully somebody will correct me if not), it's kind of a silly test; you might instead just do self.failUnless(mo is saved_mo) -- PW --~--~-~--~~~---~--~~ 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: Overriding the JOIN type in contrib.admin's search forms?
Nobody cares?
To me this seems like a significant bug in contrib.admin ... okay I'm
filing it as such:
http://code.djangoproject.com/ticket/7528
- PW
On Jun 17, 2:08 pm, Paul Winkler <[EMAIL PROTECTED]> wrote:
> Bear with me, I'm a Django novice, still reading docs...
>
> I'm trying to build my first app using django admin (release 0.96),
> because it's a good match to the requirements (a quick and simple CRUD
> application).
>
> I found a thread from last
> yearhttp://groups.google.com/group/django-users/browse_thread/thread/b086...
> where the last post describes the same problem I'm having, but there
> were no further replies.
>
> All was coming along nicely until I started using 'the lookup API
> “follow” notation' to get a foreign key into my search_fields, like
> this:
>
> class FilmClip(models.Model):
> ...
> class Admin:
> ...
> search_fields = ('clip_id', 'label', 'description',
> 'filmcliplog__description' # This is the
> line that causes problems
> )
>
> class FilmClipLog(models.Model):
> clip = models.ForeignKey(FilmClip,
> edit_inline=models.TABULAR,
> num_in_admin=3)
> ...
>
> There are two problems with the resulting behavior:
> 1) Any matching FilmClip thas has at least one FilmClipLog will show
> up in the results twice.
> 2) Any matching FilmClip that has no FilmClipLogs will not show up at
> all.
>
> From the mysql query log, I've found that the query looks like:
>
> SELECT ... FROM `filmy_filmclip` INNER JOIN `filmy_filmcliplog` ...
>
> But what I want is this:
>
> SELECT DISTINCT ... FROM `filmy_filmclip` LEFT OUTER JOIN
> `filmy_filmcliplog` ...
>
> So, my questions:
>
> 1) Is this a Django bug? When would the existing behavior be
> desirable?
>
> 2) Is there a way to specify the type of join in the search query?
>
> 3) Is there a way to add DISTINCT to the search query?
>
> 4) If no, what's the quickest way to get the behavior I want?
>
> Thanks,
>
> - PW
--~--~-~--~~~---~--~~
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: Overriding the JOIN type in contrib.admin's search forms?
On Jun 23, 11:30 pm, "Karen Tracey" <[EMAIL PROTECTED]> wrote: > It's a leap from no response to nobody cares. Yes, sorry for that, I didn't mean to be rude. > One thing, though, which may have made a lot of people pass over it is that > you are reporting a problem with they way queries are constructed on 0.96. > Since 0.96 was released the guts of the query-construction logic inside > Django has been completely rewritten. (You've probably seen this referenced > on this list -- the 'queryset-refactor' branch that was merged back into the > SVN trunk a couple of months ago.) Ah, I see. I wasn't around then, I'm brand new to Django. I don't think it's unusual to report bugs against the latest stable release though. > Can you try your scenario on current trunk? You'll probably get more > interest in a problem reported against trunk than 0.96. Certainly any fix > made for the problem will only become available in a trunk checkout and then > in 1.0; the only fixes made to 0.96 are security related. Okay, after a bit of upgrade pain I got my app running against trunk. The join type has been changed, so I get all results now; but it's not using DISTINCT so I still get the unexpected duplicates. Thanks for the help, I'll go update the bug report with the trunk behavior. --~--~-~--~~~---~--~~ 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: Overriding the JOIN type in contrib.admin's search forms?
Followup: This bug is fully fixed on the newforms_admin branch. Thanks for the help! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Bringing down a website
On Dec 13, 10:20 am, Shamail Tayyab wrote: > What could be the simplest way to do it without altering any of my > current views or anything? Write a view for /shutdown which sets some global flag eg. in the database, then write some middleware to do the rest: http://docs.djangoproject.com/en/dev/topics/http/middleware/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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.
