Signals for m2m object creation/deletion
Howdy! In short: changes to many-to-many fields do not get signalled via pre_save and post_save, but it would be useful if they got. Now all changes to model information cannot be caught. I'm doing a kind of object version control system, if it helps to understand the need. I also created a ticket on http://code.djangoproject.com/ticket/2861 The actual questions: 1) Good idea / bad idea? 2) Exactly what information it would be best to send with a signal? - samuli --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Test framework in memory database
I'm working on adding some selenium support in to the test framework.The first thing i obviously had to do was get the test server up and running at the beginning of the tests. I completed this but ran in to one large issue.The test framework defaults to using an in memory database if it sees that sqlite is set as the db type. For some reason the test environment created by the test framework with a sqlite in memory database fails when running the server. I've tested this by just running django.core.management.runserver() after the environment is setup and making a request -- the traceback is below. Of the 2 days I spent writing this, 1.5 were spent tracking this issue.Seeing this issue made me question why using an in memory database is the default test environment if it differs enough to cause this problem. I removed the in memory default from the framework (although if you configure TEST_SERVER_NAME to ":memory:" it'll still work) and patched the db creation and removal code to account for sqllite in both cases. I've also written HttpTestCase, which inherits from unittest.TestCase and handles the startup and shutdown of the test server.After finishing this I realized it's quite useful on it's own, even without the selenium bindings. I'm attaching the diff to this mail but I don't know if I should just add this patch as an attachment to my current task 2867 for Selenium support in the test framework or if I should create a new task for adding live http testing support to the test framework and then attach it to that task.Thanks,-Mikeal
http_test_case.diff
Description: Binary data
---Here is the traceback from the earlier issue when using the in memory database.$ python manage.py testCreating test database...Creating table auth_messageCreating table auth_groupCreating table auth_userCreating table auth_permissionCreating table django_content_typeCreating table django_sessionCreating table django_siteCreating table django_admin_logCreating table django_flatpageInstalling index for auth.Message modelInstalling index for auth.Permission modelInstalling index for admin.LogEntry modelValidating models...0 errors found.Django version 0.96-pre, using settings 'trunk.settings'Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/servers/basehttp.py", line 272, in run self.result = application(self.environ, self.start_response) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/servers/basehttp.py", line 614, in __call__ return self.application(environ, start_response) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/handlers/wsgi.py", line 189, in __call__ response = middleware_method(request, response) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/contrib/sessions/middleware.py", line 81, in process_response session_key = request.session.session_key or Session.objects.get_new_session_key() File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/contrib/sessions/models.py", line 21, in get_new_session_key self.get(session_key=session_key) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/db/models/manager.py", line 67, in get return self.get_query_set().get(*args, **kwargs) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/db/models/query.py", line 211, in get obj_list = list(clone) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/db/models/query.py", line 103, in __iter__ return iter(self._get_data()) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/db/models/query.py", line 430, in _get_data self._result_cache = list(self.iterator()) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/db/models/query.py", line 172, in iterator cursor.execute("SELECT " + (self._distinct and "DISTINCT " or "") + ",".join(select) + sql, params) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/db/backends/sqlite3/base.py", line 88, in execute return Database.Cursor.execute(self, query, params)OperationalError: no such table: django_sessionTraceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/servers/basehttp.py", line 272, in run self.result = application(self.environ, self.start_response) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/servers/basehttp.py", line 614, in __call__ return self.application(environ, start_response) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.
Re: Test framework in memory database
Hey Mikael, On Thu, 2006-10-05 at 20:16 -0700, Mikeal Rogers wrote: > I'm working on adding some selenium support in to the test framework. > > > The first thing i obviously had to do was get the test server up and > running at the beginning of the tests. I completed this but ran in to > one large issue. > > > The test framework defaults to using an in memory database if it sees > that sqlite is set as the db type. For some reason the test > environment created by the test framework with a sqlite in memory > database fails when running the server. I've tested this by just > running django.core.management.runserver() after the environment is > setup and making a request -- the traceback is below. Of the 2 days I > spent writing this, 1.5 were spent tracking this issue. > > > Seeing this issue made me question why using an in memory database is > the default test environment if it differs enough to cause this > problem. I removed the in memory default from the framework (although > if you configure TEST_SERVER_NAME to ":memory:" it'll still work) and > patched the db creation and removal code to account for sqllite in > both cases. I've also written HttpTestCase, which inherits from > unittest.TestCase and handles the startup and shutdown of the test > server. Excuse me for being very dense here, but I'm missing what's going on here. You found a problem with in-memory SQLite and then did or didn't solve it? Or you just worked around it? Signed, Confused. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Test framework in memory database
> Excuse me for being very dense here, but I'm missing what's going on > here. You found a problem with in-memory SQLite and then did or didn't > solve it? Or you just worked around it? Sorry for the confusion. I worked around it. It's still an outstanding issue, I'm not that familiar with the differences between using an in memory database and using regular sqlite and have hit my limit on being able to track it. I've also never ran the django test server using in memory sqlite outside the test framework so I haven't figured out if this is a general issue with the django test server or just with the test framework+django test server. Seeing the issue made me question why the framework defaulted to this so I changed it in this patch and wrote in removal support for regular sqlite (which didn't exist previously). Note: I've added in some more comment and removed some old imports from previous debugging, once I know where I should attach it this will be in a new patch. -Mikeal --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Test framework in memory database
Mikeal Rogers wrote: > > Excuse me for being very dense here, but I'm missing what's going on > > here. You found a problem with in-memory SQLite and then did or didn't > > solve it? Or you just worked around it? > > Sorry for the confusion. > > I worked around it. It's still an outstanding issue, I'm not that > familiar with the differences between using an in memory database and > using regular sqlite and have hit my limit on being able to track it. I'd bet this is related to some issues I've seen in trying to get the multi-db branch tests passing post r3661. The trouble is (or seems to me to be) that anything that uses the test client causes the request_finished signal to fire, which causes connection.close() to be called, which makes the in-memory database go away, or at least lose all of the tables, etc, that were populated into it during the "request". JP --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Test framework in memory database
On 10/6/06, JP <[EMAIL PROTECTED]> wrote: > > I'd bet this is related to some issues I've seen in trying to get the > multi-db branch tests passing post r3661. The trouble is (or seems to > me to be) that anything that uses the test client causes the > request_finished signal to fire, which causes connection.close() to be > called, which makes the in-memory database go away, or at least lose > all of the tables, etc, that were populated into it during the > "request". r3723 added a modification to make connection.close() a no-op for in-memory databases to address this exact problem. In my case, the second test client test that was executed was failing because the request_finished signal for the first test was closing the connection and dropping tables. It looks like this change has been merged into multi-db, so I can't say I know why the tables would be dropped in your case. 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 -~--~~~~--~~--~--~---
