Tackling ZODB support in Models
I've been developing some fun stuff with django for about a month now and I've been thinking of taking on a big challenge, adding ZODB support to Models. I _love_ the django models, but there are a few things I wish to do in which I need a full object persistence. I'm sending this to the list before diving head in to this task because I'm wondering: a) Is there someone already doing this :) b) Can anyone see right away huge issues that I'll run in to in the implementation. and c) Is this going to be significantly harder now rather than later. What I mean is, is there already good support for going in and supporting a new DB type that isn't likely to change much before 1.0 or should I just wait until 1.0 For those that don't know, or just cringe at the mention of something from Zope, ZODB is a very cool, very modular multi-use object persistence database. The advantage to using it would be that you could dynamically create python objects and store them in your chosen storage (filesystem, subversion, BerkeleyDB, etc) and reap the benefits of persistence and indexing. -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: would is_loggedin be better than is_anonymous?
I can see a use case where you use 'anonymous' as a kind of temporary account for users who access the site in some way other than the usual means.For example if a user gets an invitation to something, like an evite or calendar, an url could be generated that auto-authenticated them into the 'anonymous' account, which would mean they were authenticated but limited to a temporary anonymous account and would only have limited use.-MikealOn Jul 14, 2006, at 2:53 PM, SmileyChris wrote:Hrm... Will there ever be a difference between "user.is_anonymous" and "not user.is_authenticated"? If not (and I can't think of a reason), do we really need to keep is_anonymous? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
CustomAddManipulator -- Is this useful to anyone else?
I have to update multiple models a lot via post, and I love the
django AddManipulators but they don't help that much out of the box
because they are tied to a specific model.
I wrote this as a way to define CustomAddManipulators that relate
fields to multiple models and get all the benefit of the
AddManipulators tied to those models.
Before i start using it widely, I wanted some input on the approach
and see if it's django-ish enough. fast enough, and if it's useful to
anyone else and I should bother trying to contribute it once
completed :)
I tried to make it's usage after definition exactly like that of a
manipulator that was tied to a single specific model.
---
class CustomAddManipulator(forms.Manipulator):
manipulators = []
def get_manipulators(self):
for model in self.models:
exec('manipulator = %s.AddManipulator()' % model[0])
self.manipulators.append(manipulator)
def breakup_data(self, data):
new_data = []
for model in self.models:
new_model_data = {}
for key in model[1]:
new_model_data[key] = data[key]
new_data.append(new_model_data)
return new_data
def do_html2python(self, data):
if len(self.manipulators) is 0:
self.get_manipulators()
new_data = self.breakup_data(data)
for manipulator in self.manipulators:
manipulator.do_html2python(new_data
[self.manipulators.index(manipulator)])
def save(self, data):
# Method will go through model definitions and do
appropriate saves.
if len(self.manipulators) is 0:
self.get_manipulators()
new_data = self.breakup_data(data)
for manipulator in self.manipulators:
manipulator.save(new_data[self.manipulators.index
(manipulator)])
class UsageExample(CustomAddManipulator):
def __init__(self):
self.fields = (
forms.LargeTextField(field_name='content',
is_required=True),
forms.LargeTextField(field_name='content2',
is_required=True),
forms.LargeTextField(field_name='blah', is_required=True),
)
self.models = (('Model1',('content', 'blah')), ('Model2',
('content2', 'blah')))
--~--~-~--~~~---~--~~
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: CustomAddManipulator -- Is this useful to anyone else?
You could just steal the field from the manipulator containing the
references.
Wouldn't this work;
class Model1(models.Model):
content = models.CharField(maxlength=100)
blah = models.CharField(maxlength=100)
ref_model2 = models.ForeignKey(Model2)
class UsageExample(CustomAddManipulator):
def __init__(self):
self.fields = [
forms.LargeTextField(field_name='content',
is_required=True),
forms.LargeTextField(field_name='content2',
is_required=True),
forms.LargeTextField(field_name='blah', is_required=True),
]
self.get_manipulators()
for field in self.manipulators[0].fields:
if field.field_name == 'ref_model2':
self.fields.append(field)
self.models = (('Model1',('content', 'blah', 'ref_model2')),
('Model2', ('content2', 'blah')))
Is that sufficient? I was thinking that a nice addition to
CustomAddManipulator would be a default __init__(), that pulled in
the manipulators for all the models and grabbed all the fields in
those models. Then you could just define;
class Usage(CustomAddManipulator):
models = (('Model1',('content', 'blah', 'ref_model2')),
('Model2', ('content2', 'blah')))
And get all the necessary fields.
I just realized the issue that you were actually trying to bring up,
which is how to define a relationship between the instance of Model1
and Model2 being created. Since I'm just leveraging the
AddManipulators tied to models I can't see a way of doing that and
preserving the feel of a model-tied manipulator.
-Mikeal
On Aug 4, 2006, at 1:46 AM, Aidas Bendoraitis wrote:
>
> As far as I understand, these two models are absolutely separate (just
> haing the same field "blah"). What about models with relationships? I
> think, that is a tricky part. Especially, when the relationship is not
> obligatory. Do you have any ideas how to implement a generic way for
> that?
>
> Regards,
> Aidas Bendoraitis [aka Archatas]
>
> On 8/4/06, Mikeal Rogers <[EMAIL PROTECTED]> wrote:
>>
>> I have to update multiple models a lot via post, and I love the
>> django AddManipulators but they don't help that much out of the box
>> because they are tied to a specific model.
>>
>> I wrote this as a way to define CustomAddManipulators that relate
>> fields to multiple models and get all the benefit of the
>> AddManipulators tied to those models.
>>
>> Before i start using it widely, I wanted some input on the approach
>> and see if it's django-ish enough. fast enough, and if it's useful to
>> anyone else and I should bother trying to contribute it once
>> completed :)
>>
>> I tried to make it's usage after definition exactly like that of a
>> manipulator that was tied to a single specific model.
>>
>> ---
>>
>> class CustomAddManipulator(forms.Manipulator):
>>
>> manipulators = []
>>
>> def get_manipulators(self):
>>
>> for model in self.models:
>> exec('manipulator = %s.AddManipulator()' % model[0])
>> self.manipulators.append(manipulator)
>>
>> def breakup_data(self, data):
>>
>> new_data = []
>>
>> for model in self.models:
>> new_model_data = {}
>> for key in model[1]:
>> new_model_data[key] = data[key]
>> new_data.append(new_model_data)
>>
>> return new_data
>>
>> def do_html2python(self, data):
>>
>> if len(self.manipulators) is 0:
>> self.get_manipulators()
>>
>> new_data = self.breakup_data(data)
>>
>> for manipulator in self.manipulators:
>> manipulator.do_html2python(new_data
>> [self.manipulators.index(manipulator)])
>>
>> def save(self, data):
>> # Method will go through model definitions and do
>> appropriate saves.
>>
>> if len(self.manipulators) is 0:
>> self.get_manipulators()
>>
>> new_data = self.breakup_data(data)
>>
>> for manipulator in self.manipulators:
>> manipulator.save(new_data[self.manipulators.index
>> (manipulator)])
>>
>> class UsageExample(CustomAddManipulator):
>> def __init__(self):
>> self.fields = (
>> forms.LargeTextField(field_name=
Using test.client.Client.post with body?
I'm a little confused as to how to really use the test client for a json-rpc request. I need to send a serialized object in the body, but the method seems to be designed to simulate form post and may not contain this option. Is there a way to do this that I'm missing or does this need to be added. I think most of my confusion surrounding this is that I'm used to using httplib to make these requests, but the client test tool seems to make it's requests directly to the request handler apis. A note about this in the documentation would really be helpful since I wouldn't have guessed this without looking through the source. -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 -~--~~~~--~~--~--~---
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
> 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: GSoC 2009: Testing Upgrades/Awesomeness
Figured I should chime in on this. I'm one of the co-creators of the Windmill project and I thought I should clarify the different levels of support Windmill has for django and nose. Windmill tests have a fairly integrated test framework of their own. Many months back we added a feature that allowed django projects to define a unittest class that bootstrapped the windmill framework to run tests inside django's testing framework. This solution was somewhat hacky as it meant that a single pass or fail was returned to django's testing framework. This support also overrides some django TestCase internals to do what (http://code.djangoproject.com/ticket/ 2879) adds. During the PyCon sprints I wrote the management command, which starts up the django test server and starts windmill directly. This meant that the tests showed pass/fail for every test and showed tracebacks for failed tests and returned sys.exit(1) on any failures and all that good stuff. This solution discovers your windmill tests in your django applications and doesn't override any of the django TestCase internals and is the most elegant solution for running django windmill tests thus far. http://trac.getwindmill.com/wiki/WindmillAndDjango#Usingmanage.pytest_windmill If you are moving to nose you should also know that windmill has a great nose plugin. In fact the nose plugin doesn't have to start up windmill's testing framework at all as nose's format for setup/ teardown of modules is compatible with windmill's. http://trac.getwindmill.com/wiki/BookChapter-5-RunningTests#RunningTestsfromNose If you have any questions or concerns we are very attentive to our dev list (http://groups.google.com/group/windmill-dev) and we are also very active on IRC (#windmill or irc.freenode.net) -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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
