Re: running the unit tests in the schema evolution branch
Victor Ng wrote: > The tests don't look like they're integrated with runtests.py at all. no, they're standalone. > 3) Run reset_all_to_pre (note that this doesn't have a shebang at the top) > 5) Run reset_all_to_post (note that this script also doesn't have a > shebang at the top) we're all running bash, aren't we? ;p > So do basically something like this: > > cd branches/schema-evolution/tests/evolvedbtests > ./rest_all_to_pre > python manage.py syncdb > ./reset_all_to_post > python manage.py sqlevolve case01_add_field > python manage.py sqlevolve case02_rename_field > python manage.py sqlevolve case03_rename_model > python manage.py sqlevolve case04_change_flag > python manage.py sqlevolve case05_remove_field yep, except you should add: ./rest_all_to_pre python manage.py sqlevolve case01_add_field python manage.py sqlevolve case02_rename_field python manage.py sqlevolve case03_rename_model python manage.py sqlevolve case04_change_flag python manage.py sqlevolve case05_remove_field to prove it all works full circle. > There doesn't seem to be any automation around what the expected SQL > output is, and as far as I can tell, this only works on the mysql > backend. it should work on all three, with the exception of remove_field under sqlite (for obvious reasons) > The emitted output on my machine is always empty. I always get this: > > ~/svk-ws/remote/mb-django/branches/schema-evolution/tests/evolvedbtests> > python manage.py sqlevolve case01_add_field > BEGIN; > COMMIT; > Which is obviously not what I really want. > Any thoughts? check to make sure you've switched your symlinks from pre to post (or back again) since your last sync, and that the models actually are different than the tables in your db. (i can't tell you how many times this summer i was asking myself "wtf" for this exact reason) -- derek --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Should we have another 'post_save' signal?
I just override safe_file for the FileField. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: strange exclude behavior
-- continue -- Entering the next query in psql returns the correct collection: SELECT polls_poll.*, polls_vote.voter_ip FROM polls_pol LEFT OUTER JOIN polls_vote ON polls_poll.id = polls_vote.poll_id WHERE polls_vote.voter_ip <> '192.168.1.10' OR polls_vote.voter_ip IS NULL; Can this query be constructed using filter or exclude or do I have to use a custom query? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: strange exclude behavior
I found a solution using a custom query in models.py def get_unvoted_polls_for_voter_ip(ip): from django.db import connection cursor = connection.cursor() sql = """SELECT polls_poll.id, polls_poll.question FROM polls_poll LEFT OUTER JOIN polls_vote ON polls_poll.id = polls_vote.poll_id WHERE polls_vote.voter_ip <> '%s' OR polls_vote.voter_ip IS NULL;""" % ip cursor.execute(sql) list = cursor.fetchall() return list Now I want to create poll objects from the result but I dont know how. Any idea? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: strange exclude behavior
Hi Rob, Rob Slotboom wrote: > I found a solution using a custom query in models.py > > def get_unvoted_polls_for_voter_ip(ip): >from django.db import connection >cursor = connection.cursor() >sql = """SELECT polls_poll.id, polls_poll.question FROM polls_poll > LEFT OUTER JOIN polls_vote ON polls_poll.id = polls_vote.poll_id > WHERE polls_vote.voter_ip <> '%s' OR polls_vote.voter_ip IS > NULL;""" % ip >cursor.execute(sql) >list = cursor.fetchall() >return list > > Now I want to create poll objects from the result but I dont know how. > Any idea? Hmm, there's a separate list for asking this type of questions, it's django-users. You're welcome here, and often questions are answered here, too, but here it is more for people developing and modifying django, and these are a lot fewer than on the user list, especially at this time of the day (hint, hint ;-) That said, you probably want to do something like poll = Poll(id=...,question=...) or perhaps use the bulk_in method in QuerySet. There might exist better (more elegant solutions), though, so better really re-raise your question on the user list, or try something with dictfetchall. Michael --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
0.91-bugfixes: response middleware applied even though request middleware returned a response
I just ran into a problem caused by response middleware getting called even though request middleware returned a response. The docs, even in 0.91, claim that all response processing stops if request middleware returns a response, but this was not the case, even on trunk, until [2358], while 0.91 was [1908]. This was (possibly inadvertently) fixed in that changeset by returning from get_response, which bypasses the later code that used to be in ModPythonHandler.__call__. This is the third or so request to have a bug applied to 0.91-bugfixes. I'm not at all upset, but the prior requests haven't been answered. Would it be possible for me to gain committer access on that branch? I'm fixing bugs over there anyway. ;-) Cheers, Jeremy --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: 0.91-bugfixes: response middleware applied even though request middleware returned a response
On 11/10/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > This is the third or so request to have a bug applied to > 0.91-bugfixes. I'm not at all upset, but the prior requests haven't > been answered. Would it be possible for me to gain committer access > on that branch? I'm fixing bugs over there anyway. ;-) Can you point me to the other requests? Also, I'll put this on my to-do list and try to patch it over the weekend. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: running the unit tests in the schema evolution branch
Thanks for the heads up on the symlinks. My problem was with stale pyc files created by symlinked .py files. Blech. What version of sqlite and pysqlite were you testing on? I can get SQL output from mysql and psycopg1 now, but nothing out of sqlite3. vic > > The emitted output on my machine is always empty. I always get this: > > > > ~/svk-ws/remote/mb-django/branches/schema-evolution/tests/evolvedbtests> > > python manage.py sqlevolve case01_add_field > > BEGIN; > > COMMIT; > > > Which is obviously not what I really want. > > Any thoughts? > > check to make sure you've switched your symlinks from pre to post (or > back again) since your last sync, and that the models actually are > different than the tables in your db. (i can't tell you how many times > this summer i was asking myself "wtf" for this exact reason) > > -- derek --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: 0.91-bugfixes: response middleware applied even though request middleware returned a response
On 11/10/06, James Bennett <[EMAIL PROTECTED]> wrote: > Can you point me to the other requests? > Apparently, I exaggerated. I could only find one other request, at the end of this thread: http://groups.google.com/group/django-developers/browse_thread/thread/587004d127dd9444/5ffe71f43a099d22?lnk=gst&q=A+final+post-0.91+release&rnum=1#5ffe71f43a099d22 I'm working on a list of other fixes I've made or have applied to our flavor of 0.91. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
a small typo in #3007/r4058
Hello people. There is a small bug/typo in patch came with r4058 revision. random_bits variable became string instead of integer, so the following: -msg['Message-ID'] = "<[EMAIL PROTECTED]>" % (time.time(), random_bits, DNS_NAME) should be changed to: +msg['Message-ID'] = "<[EMAIL PROTECTED]>" % (time.time(), random_bits, DNS_NAME) BTW, I've tried to reopen #3007, but got the following message: Submission rejected as potential spam (Akismet says content is spam) -- Igor Goryachev E-Mail/Jabber: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: a small typo in #3007/r4058
On 11/10/06, Igor Goryachev <[EMAIL PROTECTED]> wrote: > There is a small bug/typo in patch came with r4058 revision. Thanks for the report, Igor! I've made the fix. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Traceback when using locmem cache backend
Hi there, Akismet rejects ticket as spam, so posting it here. A couple of months or so ago i started to get this traceback on sequential reloads of specific page. Seems it also affects other users, there is notice of it here http://simon.bofh.ms/logger/django/2006/10/08/ (search for 'not safe'). Running latest trunk here. I can give any additional info if needed. Would like to debug it myself but my knowledge of django internals is not so good for this.. Mod_python error: "PythonHandler django.core.handlers.modpython" Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/mod_python/apache.py", line 299, in HandlerDispatch result = object(req) File "/usr/lib/python2.5/site-packages/django/core/handlers/modpython.py", line 177, in handler return ModPythonHandler()(req) File "/usr/lib/python2.5/site-packages/django/core/handlers/modpython.py", line 150, in __call__ response = self.get_response(request) File "/usr/lib/python2.5/site-packages/django/core/handlers/base.py", line 59, in get_response response = middleware_method(request) File "/usr/lib/python2.5/site-packages/django/middleware/cache.py", line 60, in process_request response = cache.get(cache_key, None) File "/usr/lib/python2.5/site-packages/django/core/cache/backends/locmem.py", line 23, in get return copy.deepcopy(self._cache[key]) File "/usr/lib/python2.5/copy.py", line 189, in deepcopy y = _reconstruct(x, rv, 1, memo) File "/usr/lib/python2.5/copy.py", line 337, in _reconstruct state = deepcopy(state, memo) File "/usr/lib/python2.5/copy.py", line 162, in deepcopy y = copier(x, memo) File "/usr/lib/python2.5/copy.py", line 254, in _deepcopy_dict y[deepcopy(key, memo)] = deepcopy(value, memo) File "/usr/lib/python2.5/copy.py", line 189, in deepcopy y = _reconstruct(x, rv, 1, memo) File "/usr/lib/python2.5/copy.py", line 322, in _reconstruct y = callable(*args) File "/usr/lib/python2.5/copy_reg.py", line 92, in __newobj__ return cls.__new__(cls, *args) TypeError: object.__new__(listiterator) is not safe, use listiterator.__new__() Regards, Alex --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Traceback when using locmem cache backend
On 11/11/06, Alex Dedul <[EMAIL PROTECTED]> wrote: > > Hi there, > > Akismet rejects ticket as spam, so posting it here. Thanks for the report, Alex. Some changes have been made to our ticket setup to get around these spam rejections; if you go to the settings page (link on the bottom right of every page), you should be able to provide a name and email address which should get you through the spam filter. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Branch Merges?
Michael Radziej wrote: > Adrian Holovaty schrieb: >> That's a good point. Maybe we could do a better job of this by >> highlighting the currently developed branches on the main Django >> download page, rather than hiding them on the wiki, which I'm still >> convinced many people don't know about. Thoughts? > > Another proposal: > > Let's have a branch of the month, announced on devel and users. The > branch is then frozen, merged with trunk, and will be merged at a fixed > date into trunk if no critical and unfixable bugs are found. This would > encourage at least me to check this branch out and test it well before > the merge ;-) Branch Tuesday ;) Though I run some commercial projects using an unstable-trunk, policy, I like the stable-trunk approach for Django. It clearly has worked well. In any case, the way to solve branch testing isn't to make the trunk unstable as a convenience. I guess two questions to ask now are a) how many of these branches are realistically going to land, ever, and b) which ones are considered high value, so we can focus on testing those? cheers Bill --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Traceback when using locmem cache backend
Russell Keith-Magee wrote: > On 11/11/06, Alex Dedul <[EMAIL PROTECTED]> wrote: >> Hi there, >> >> Akismet rejects ticket as spam, so posting it here. > > Thanks for the report, Alex. > > Some changes have been made to our ticket setup to get around these > spam rejections; if you go to the settings page (link on the bottom > right of every page), you should be able to provide a name and email > address which should get you through the spam filter. Thanks for the hint, created ticket #3012 Regards, Alex --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Branch Merges?
Let's *please* keep the trunk stable. It would be very discouraging to new developers if they checked out Django from SVN head and got a broken source tree. On the topic of which branches will ever land - I'm actively working on schema evolution right now. There's still a fair bit of work to make it stable but it *is* being worked on.I'm hoping to have code ready for review within a week. vic On 11/10/06, Bill de hOra <[EMAIL PROTECTED]> wrote: > > In any case, the way to solve branch testing isn't to make the trunk > unstable as a convenience. I guess two questions to ask now are a) how > many of these branches are realistically going to land, ever, and b) > which ones are considered high value, so we can focus on testing those? -- "Never attribute to malice that which can be adequately explained by stupidity." - Hanlon's Razor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
