Hi Nikolaus,

Nikolaus Schlemm schrieb:

It would be easier to comment on it if you would provide a patch
with full path, so that track can recognize its context and
display it properly. Look at the other patches if you don't see how.

I'd like to have a way to control through which foreign key
fields it should expand, since I might not need all the data.
That's also a point with the current implementation: It doesn't
let me skip data fields not needed.

Anyway, how is this supposed to behave for a chain of foreign
keys? Would it go through all the related models and the models
related to the related models, etc.?

Michael

hi Michael,

after looking at other patches, I now called "svn diff" from the django
root-dir and attached that, but unfortunately trac still won't display it
properly. is there anything else that needs to be done with it?

that's a valid point, but possilby an issue of its own. currently, the export
of one2many relations would be controlled by a boolean. but in generally
speaking, I think the fields to be exported could be passed in as a list
parameter..

nope, this simply compiles a list of the primary keys of the "many" related
models when you export the "one" - similarly to how many2many relations are
exported.
--
cheers,

        Nikl

more and more I'm thinking this is definitely an excellent idea!! e.g. you
wouldn't necessarily want to export password fields ;)
--
cheers,

        Nikl

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

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


------------------------------------------------------------------------
-------

Here is the traceback from the earlier issue when using the in memory  
database.

$ python manage.py test
Creating test database...
Creating table auth_message
Creating table auth_group
Creating table auth_user
Creating table auth_permission
Creating table django_content_type
Creating table django_session
Creating table django_site
Creating table django_admin_log
Creating table django_flatpage
Installing index for auth.Message model
Installing index for auth.Permission model
Installing index for admin.LogEntry model

Validating 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_session
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_session

Hey Mikael,

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.

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

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

On 10/6/06, JP <jpelle...@gmail.com> wrote:

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 %-)

 Doesnt look like anyone has. What sort of thing did you have in mind?

 A way of producing little monthly calendars with highlighted days when
events occur?

 A whole set of Year-, month-, week- and day-per page templates?

 There should be plenty of python code around to help with these
things, the template of course will be nice simple markup HTML with
some stylesheet goodness.

Barry