Bug: Underscores in primary keys and quote/unquote...
I have a model class like this:
class PagesInternal(models.Model):
name = models.CharField(primary_key=True, maxlength=150)
...
And my names (the primary keys) contains unterscore, like this:
"page_admin.edit_page"
I used no ID for the primary key, because i "addressed" the entries
about the names.
I used the unicode-branch and get a error, if i edit a entry in this
model with the django admin panel:
Traceback (most recent call last):
File "./django/core/handlers/base.py" in get_response
72. response = middleware_method(request, callback, callback_args,
callback_kwargs)
File "./PyLucid/middlewares/pagestats.py" in process_view
45. response = view_func(request, *view_args, **view_kwargs)
File "./django/contrib/admin/views/decorators.py" in _checklogin
55. return view_func(request, *args, **kwargs)
File "./django/views/decorators/cache.py" in _wrapped_view_func
39. response = view_func(request, *args, **kwargs)
File "./django/contrib/admin/views/main.py" in change_stage
324. manipulator = model.ChangeManipulator(object_id)
File "./django/db/models/manipulators.py" in __init__
261. self.original_object = self.manager.get(pk=obj_key)
File "./django/db/models/manager.py" in get
73. return self.get_query_set().get(*args, **kwargs)
File "./django/db/models/query.py" in get
258. obj_list = list(clone)
File "./django/db/models/query.py" in __iter__
111. return iter(self._get_data())
File "./django/db/models/query.py" in _get_data
478. self._result_cache = list(self.iterator())
File "./django/db/models/query.py" in iterator
186. cursor.execute("SELECT " + (self._distinct and "DISTINCT " or
"") + ",".join(select) + sql, params)
File "./django/db/backends/util.py" in execute
23. 'sql': smart_unicode(sql) % convert_args(params),
File "./django/db/backends/util.py" in convert_args
50. return tuple([to_unicode(val) for val in args])
File "./django/db/backends/util.py" in
48. to_unicode = lambda s: force_unicode(s, strings_only=True)
File "./django/utils/encoding.py" in force_unicode
42. s = unicode(s, encoding, errors)
UnicodeDecodeError at /_admin/PyLucid/pagesinternal/
page_admin.edit_page/
'utf8' codec can't decode byte 0xad in position 4: unexpected code
byte
But i think this is not a real UnicodeDecodeError... It's a problem
with the quote()/unquote() routines in
django.contrib.admin.views.main.py
The string before unquote() is..: page_admin.edit_page
The string after unquote() is...: page\ufffdmin.edit_page
In a local test, it seems to work fine:
from django.contrib.admin.views.main import quote, unquote
TEST_STRING = "page_admin.edit_page"
q = quote(TEST_STRING)
print "quote():", q
print "unquote():", unquote(q)
print
print "unquote()2:", unquote(TEST_STRING)
output:
quote(): page_5Fadmin.edit_5Fpage
unquote(): page_admin.edit_page
unquote()2: page\ufffdmin.edit_page
But, in my case, the real input for unquote() is not the quoted one
like "page_5Fadmin.edit_5Fpage"!
It is the non-quoted one like: "page_admin.edit_page"
And then the unquote() break the string into: "page
\ufffdmin.edit_page"
It this a django bug?
--
Mfg.
Jens Diemer
A django powered CMS: http://www.pylucid.org
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Use of django.db.models.signals.class_prepared in the wild?
Hello all, I'm trying to document uses of django signals in preparation for a presentation. I'm having some trouble finding any uses of class_prepared. I imagine this is because the class_prepared signal is sent so early in Django's startup, but am curious: Does anyone know of an example other than the deferred hookups in Django itself? -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: 4102, updating only specific fields / dirty flag
I was trying to bump the previous thread: http://groups.google.com/group/django-developers/browse_thread/thread/b8e2eaa6b5190b19/7e608ee8822d3a60 But Google Groups won't let me reply to it (maybe it's too old?) ;) The reason was the new patches, with the attempt at a 'dirty' flag so that it only has to update fields that changed. It occurs to me as I type this that a "force" option to save might go well with this to make it save everything regardless, but I'm still not sure if I'm missing any obvious gotchas in the current attempt :) --~--~-~--~~~---~--~~ 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: Bug: Underscores in primary keys and quote/unquote...
On Tue, 2007-06-26 at 01:30 -0700, jedie wrote: > > I have a model class like this: > > class PagesInternal(models.Model): > name = models.CharField(primary_key=True, maxlength=150) > ... > > > And my names (the primary keys) contains unterscore, like this: > "page_admin.edit_page" > > I used no ID for the primary key, because i "addressed" the entries > about the names. > [...] > UnicodeDecodeError at /_admin/PyLucid/pagesinternal/ > page_admin.edit_page/ > 'utf8' codec can't decode byte 0xad in position 4: unexpected code > byte > > > But i think this is not a real UnicodeDecodeError... It's a problem > with the quote()/unquote() routines in > django.contrib.admin.views.main.py > > The string before unquote() is..: page_admin.edit_page > The string after unquote() is...: page\ufffdmin.edit_page > > > > > In a local test, it seems to work fine: > > > from django.contrib.admin.views.main import quote, unquote > > TEST_STRING = "page_admin.edit_page" > > q = quote(TEST_STRING) > print "quote():", q > print "unquote():", unquote(q) > print > print "unquote()2:", unquote(TEST_STRING) > > > > output: > > quote(): page_5Fadmin.edit_5Fpage > unquote(): page_admin.edit_page > > unquote()2: page\ufffdmin.edit_page > Except this isn't what your test produces. When I run that test program against the Unicode branch, I got the same result as against trunk: unquote(TEST_STRING) returns 'page\xadmin.edit_page'. And when Python tries to interpret that as at UTF-8 string, it hits the illegal byte \xad, giving the UnicodeDecodeError it reports. You are seeing \ufffd in your output because of some terminal or Python shell settings you have in effect (\ufffd is the Unicode "illegal character" replacement codepoint). Have a look at the results of repr(unquote(TEST_STRING)) to see the real data being passed around by Django. > But, in my case, the real input for unquote() is not the quoted one > like "page_5Fadmin.edit_5Fpage"! > It is the non-quoted one like: "page_admin.edit_page" So the real question is why is unquote() being called on that string, since unquote() should only ever be called on strings that have been run through quote() previously. Since the bug is crash inside change_stage() in the same file, try to work out what why the wrong string is being passed in there. This should be just pieces of input captured from the URL (via admin/urls.py), so this suggests that something is creating the wrong URL (and I thought we would have noticed that previously: it's why quote() and unquote() were written in the first place). It might also be possible that you have just lucked onto the right piece of data that demonstrates the problem. The unquote() function is resilient to bad input and it's only by accident that the first two characters the word "admin" happen to be valid hex digits, so "_ad" can be treated as an escaped sequence. So there might be a bug here, but a bit more poking around is required. Try to figure out why an unquoted URL fragment is being passed to admin in the first place (well, first check that the object_id being passed to change_stage() really is unquoted already and work backwards from there -- why is it?). Regards, Malcolm -- How many of you believe in telekinesis? Raise my hand... http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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: 4102, updating only specific fields / dirty flag
On Tue, 2007-06-26 at 03:30 -0700, Collin Grady wrote: > I was trying to bump the previous thread: > > http://groups.google.com/group/django-developers/browse_thread/thread/b8e2eaa6b5190b19/7e608ee8822d3a60 > > But Google Groups won't let me reply to it (maybe it's too old?) ;) > > The reason was the new patches, with the attempt at a 'dirty' flag so > that it only has to update fields that changed. > > It occurs to me as I type this that a "force" option to save might go > well with this to make it save everything regardless, but I'm still > not sure if I'm missing any obvious gotchas in the current attempt :) One thing that jumps out from a quick read: there are no tests on the patch. One test that springs to mind is to create two instances of the same database row, change different fields and then save each one, re-query the database and prove the two saves only updated their respective columns. There might be some other cases that need testing two (relations, for example?). Paul seems to have put some tests on an earlier patch. Probably worth grabbing those and checking they are comprehensive. My second thought is that overriding __setattr__ like that has some drawbacks. It means that if any model in an application implements __setattr__, they have to remember to call the Model version as well or else nothing in core -- or any third-party app that was intended to work in conjunction with other, unknown apps -- could ever assume the parallel update condition holds in the future, if we wanted to use it. It also slows things down on the fast path a bit (when this feature isn't needed). The original version had the list of columns to save being passed into Model.save(). That feels less intrusive. I have a bit too much on my plate to move this to something I'm going to be able to look at much in the next couple of days, but those are my thoughts from reading through the latest patch. It would be very useful to time the performance impact and verify that it isn't really significant, at least. Would be interested to hear other thoughts about the API impact (adding an optional extra param to save()). Regards, Malcolm -- Honk if you love peace and quiet. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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: Bug: Underscores in primary keys and quote/unquote...
On 26 Jun., 13:53, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Since the bug is crash inside change_stage() in the same file, try to
> work out what why the wrong string is being passed in there. This should
> be just pieces of input captured from the URL (via admin/urls.py), so
> this suggests that something is creating the wrong URL (and I thought we
> would have noticed that previously: it's why quote() and unquote() were
> written in the first place).
No, i think the URL is ok.
It's the combination of "_ad"... Because the primary key "TEST_adTEST"
goes into the same traceback...
In /django/views/decorators/cache.py in _wrapped_view_func the String
is ok:
---
Line 39. | response = view_func(request, *args, **kwargs)
---
Local var "args" is -> ('PyLucid', 'pagesinternal', 'TEST_adTEST')
In the next trace /django/contrib/admin/views/main.py in change_stage
the String is broken:
---
Line 322. | manipulator = model.ChangeManipulator(object_id)
---
Local var "object_id" is -> 'TEST\xadTEST'
The method change_stage() always unquote the object_id in Line 310!
And repr(unquote("TEST_adTEST")) is -> 'TEST\xadTEST'
Note: I used the unicode branch. Does the error related to this
branch?
I implement a silly work-a-round (rename the primary keys on the fly):
http://pylucid.net/trac/changeset/1110
--
Mfg.
Jens Diemer
A django powered CMS: http://www.pylucid.org
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Status of contrib.comments rewrite?
Hi, I'm just curious, I've read somewhere (maybe here) that the contrib.comments package need to be rewritten in order to allow more flexibility (like user.get_profile) and to use newforms. I thought that's the main reason why this part is not documented. What's the status of this update? Did someone is already on this? David --~--~-~--~~~---~--~~ 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: Bug: Underscores in primary keys and quote/unquote...
On Tue, 2007-06-26 at 06:29 -0700, jedie wrote: > On 26 Jun., 13:53, Malcolm Tredinnick <[EMAIL PROTECTED]> > wrote: > > Since the bug is crash inside change_stage() in the same file, try to > > work out what why the wrong string is being passed in there. This should > > be just pieces of input captured from the URL (via admin/urls.py), so > > this suggests that something is creating the wrong URL (and I thought we > > would have noticed that previously: it's why quote() and unquote() were > > written in the first place). > > No, i think the URL is ok. > It's the combination of "_ad"... Because the primary key "TEST_adTEST" > goes into the same traceback... When I asked "is the URL okay", I meant, has it been passed through quote() correctly. Because unquote() is only meant to be run on things that have been passed through quote() and because any primary key value is meant to be passed through quote() before it goes into an admin URL, something is going wrong in the URL generation phase. I realise it's the combination of "_ad" that is the problem. That was in my original mail. The problem is to work out *why* the string "_ad" is being permitted into the URL in the first place. Why isn't it going through quote()? This might take some tracking down. It's probably a bug in Django, but any investigation you can do before filing a ticket will save somebody else some time later. There should be no difference between the Unicode branch and trunk in that behaviour, I would have thought, but file the ticket against the Unicode branch in any case, just in case it makes a difference. Malcolm -- The hardness of butter is directly proportional to the softness of the bread. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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: Status of contrib.comments rewrite?
On 6/26/07, David Larlet <[EMAIL PROTECTED]> wrote: > I'm just curious, I've read somewhere (maybe here) that the > contrib.comments package need to be rewritten in order to allow more > flexibility (like user.get_profile) and to use newforms. I thought > that's the main reason why this part is not documented. > > What's the status of this update? Did someone is already on this? I'm working on it; pretty close to a call-for-comments (sorry :) stage. Stay tuned, Jacob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Shared memory across processes
I expect this isn't the best way to ask this, but this is where the dbsettings saga has played out so far, and you guys have a good idea of what I'm trying to do, so I'm asking anyway. The biggest hurdle to dbsettings at this point is that it caches settings in a standard Python module, which only exists within a single process. This was all well and good while developing it, but people are now starting to try it under mod_python, which (depending on the Apache MPM) creates multiple processes, each with their own dbsettings cache. This is fine except when editing settings, since it can only update the cache in the current process. I did a bit of research on this topic, and it seems to be a fairly prickly issue. I obviously can't restrict people to mpm-winnt[1], so something would have to be done as part of the application. I considered simply requiring projects to use Django's cache framework, but the only backend that would really do the job is memcached, and that again adds another dependency for what should be a simple application. I considered locmem, but as far as I can tell, that's just a thread-safe version of simple, so it still doesn't share memory across processes. I've also found information on POSH[2] and ZODB[3], but I really don't like the idea of relying on yet another dependency for this. I'll probably look into both of those to see if there's anything generic I can pull out though. Has anybody on here ever had a need to do something like this? If so, are there other decent solutions available? -Gul [1] http://www.modpython.org/pipermail/mod_python/2006-August/021939.html [2] http://sourceforge.net/projects/poshmodule/ [3] http://www.zope.org/Products/ZODB3.2 --~--~-~--~~~---~--~~ 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: Requesting help from Oracle backend devs re: regex field lookups
On 6/23/07, Tom Tobin <[EMAIL PROTECTED]> wrote: > > Now that boulder-oracle-sprint has been merged into trunk, I'd like to > ask the Oracle backend developers to take a look at Ticket #1465, > implementing regular expression field lookups (i.e., > "somefield__regex=foo" or "somefield__iregex=foo"); the patch there > currently lacks support for Oracle. > > Based on docs from oracle.com [1], I *believe* the incantations for Oracle > are: > > case-sensitive: REGEXP_LIKE(field, pattern, 'c') > case-insensitive: REGEXP_LIKE(field, pattern, 'i') > > Am I on target here? Also, are there versions of Oracle usable with > Django that might not support these? > > [1] http://www.oracle.com/technology/obe/obe10gdb/develop/regexp/regexp.htm Hi Tom, You've got it right. In addition to Oracle 10g, we're also trying to support Oracle 9i, which lacks the REGEXP_LIKE condition. However, Oracle is ending support for 9i this month, so I don't think that we necessarily need to support new Django features against 9i as long as the documentation notes that 10g is required. Let me know if I can be of any other help, e.g. with testing. Thanks, Ian --~--~-~--~~~---~--~~ 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: Requesting help from Oracle backend devs re: regex field lookups
On 6/26/07, Ian Kelly <[EMAIL PROTECTED]> wrote: > > On 6/23/07, Tom Tobin <[EMAIL PROTECTED]> wrote: > > > > Am I on target here? Also, are there versions of Oracle usable with > > Django that might not support these? > > Hi Tom, > > You've got it right. In addition to Oracle 10g, we're also trying to > support Oracle 9i, which lacks the REGEXP_LIKE condition. However, > Oracle is ending support for 9i this month, so I don't think that we > necessarily need to support new Django features against 9i as long as > the documentation notes that 10g is required. > > Let me know if I can be of any other help, e.g. with testing. I've updated the attached patch on the ticket [1]; if you could test it out under Oracle (both trying the field lookups directly, and running the testing framework) that would be a huge help. :-) [1] http://code.djangoproject.com/attachment/ticket/1465/regex-field-lookups.patch --~--~-~--~~~---~--~~ 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: Shared memory across processes
On 6/26/07, Marty Alchin <[EMAIL PROTECTED]> wrote: ... > Has anybody on here ever had a need to do something like this? If so, > are there other decent solutions available? Assuming I've understood the issue, and if you don't expect concurrent writes, consider a BDB. Also, these may or may not be interesting: http://www.dekorte.com/projects/opensource/ --~--~-~--~~~---~--~~ 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: Shared memory across processes
On 6/26/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > Assuming I've understood the issue, and if you don't expect concurrent > writes, consider a BDB. > > Also, these may or may not be interesting: > http://www.dekorte.com/projects/opensource/ Well, the dekorte stuff looks interesting, but I'm certainly not about to impose a requirement like that as a dbsettings prerequisite. I don't want to make people have to compile something separate just to use this. BDB may be an option, as I expect it's a fair bit more common, but I'm still hoping there's a simple shared memory solution out there where I can just dump a Python dictionary and have all the process read from it. Definitely worth looking into though, thanks for the help. -Gul --~--~-~--~~~---~--~~ 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: Requesting help from Oracle backend devs re: regex field lookups
On 6/26/07, Ian Kelly <[EMAIL PROTECTED]> wrote: > > Let me know if I can be of any other help, e.g. with testing. Thanks for helping me catch that bug; I think the patch is finally ready to be committed. :-) --~--~-~--~~~---~--~~ 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: Shared memory across processes
Marty Alchin wrote: > I expect this isn't the best way to ask this, but this is where the > dbsettings saga has played out so far, and you guys have a good idea > of what I'm trying to do, so I'm asking anyway. > > The biggest hurdle to dbsettings at this point is that it caches > settings in a standard Python module, which only exists within a > single process. This was all well and good while developing it, but > people are now starting to try it under mod_python, which (depending > on the Apache MPM) creates multiple processes, each with their own > dbsettings cache. This is fine except when editing settings, since it > can only update the cache in the current process. > > I did a bit of research on this topic, and it seems to be a fairly > prickly issue. I obviously can't restrict people to mpm-winnt[1], so > something would have to be done as part of the application. I > considered simply requiring projects to use Django's cache framework, > but the only backend that would really do the job is memcached, and > that again adds another dependency for what should be a simple > application. > > I considered locmem, but as far as I can tell, that's just a > thread-safe version of simple, so it still doesn't share memory across > processes. I've also found information on POSH[2] and ZODB[3], but I > really don't like the idea of relying on yet another dependency for > this. I'll probably look into both of those to see if there's anything > generic I can pull out though. > > Has anybody on here ever had a need to do something like this? If so, > are there other decent solutions available? > > -Gul > > [1] http://www.modpython.org/pipermail/mod_python/2006-August/021939.html > [2] http://sourceforge.net/projects/poshmodule/ > [3] http://www.zope.org/Products/ZODB3.2 > Forgive my ignorance, but this doesn't seem like a problem that will come up too often, so the solution is going to be pretty custom. Why would you be changing db settings on the fly? Carl K --~--~-~--~~~---~--~~ 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: edit_inline support for generic relations
Excellent! I also need this sort of functionality. I'm going to try it out now and I'll give you what feedback I can. -Weston --~--~-~--~~~---~--~~ 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: Shared memory across processes
On 6/26/07, Carl Karsten <[EMAIL PROTECTED]> wrote: > Forgive my ignorance, but this doesn't seem like a problem that will come up > too > often, so the solution is going to be pretty custom. > > Why would you be changing db settings on the fly? I've put together an app called dbsettings[1] that enables a new type of setting that acn indeed by changed while the server is running. I'm planning to use it in a couple projects, and there's already been a good bit of interest in it from members of this list. There are rumors that, provided I can get things like this mod_python problem sorted out, it might even make it into the official distribution. So, the short story is, you wouldn't be changing db settings (note the space; refers to database settings in settings.py) on the fly, but you would be changing dbsettings (no space; refers to this new app) on the fly. You're not the first to confused by it, so don't feel bad. Its name has a long, sordid history that's not worth getting into again. -Gul [1] http://code.google.com/p/django-values/ --~--~-~--~~~---~--~~ 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: Shared memory across processes
Carl, Thats application settings which are stored in a db (thus dbsettings - with no space). See http://code.google.com/p/django-values/ for more info. Marty, I have not yet used your app (although I had intended to until I read this) so I assumed you had worked this out already. The thing is, if each process has to look to a central location to retrieve/update, why not use the db as that central location? Perhaps the way to go is to have an option to turn caching on or off. Then, when deployed, the user could use one of a few pluggable backends (your current implementation, memcached, etc) to get caching to work. That way, in the simple case, caching is turned off and it's not an issue. In the more complex cases, the user can choose the caching mechanism that he can provide the dependencies for if need be. On 6/26/07, Carl Karsten <[EMAIL PROTECTED]> wrote: > > Marty Alchin wrote: > > I expect this isn't the best way to ask this, but this is where the > > dbsettings saga has played out so far, and you guys have a good idea > > of what I'm trying to do, so I'm asking anyway. > > > > The biggest hurdle to dbsettings at this point is that it caches > > settings in a standard Python module, which only exists within a > > single process. This was all well and good while developing it, but > > people are now starting to try it under mod_python, which (depending > > on the Apache MPM) creates multiple processes, each with their own > > dbsettings cache. This is fine except when editing settings, since it > > can only update the cache in the current process. > > > > I did a bit of research on this topic, and it seems to be a fairly > > prickly issue. I obviously can't restrict people to mpm-winnt[1], so > > something would have to be done as part of the application. I > > considered simply requiring projects to use Django's cache framework, > > but the only backend that would really do the job is memcached, and > > that again adds another dependency for what should be a simple > > application. > > > > I considered locmem, but as far as I can tell, that's just a > > thread-safe version of simple, so it still doesn't share memory across > > processes. I've also found information on POSH[2] and ZODB[3], but I > > really don't like the idea of relying on yet another dependency for > > this. I'll probably look into both of those to see if there's anything > > generic I can pull out though. > > > > Has anybody on here ever had a need to do something like this? If so, > > are there other decent solutions available? > > > > -Gul > > > > [1] http://www.modpython.org/pipermail/mod_python/2006-August/021939.html > > [2] http://sourceforge.net/projects/poshmodule/ > > [3] http://www.zope.org/Products/ZODB3.2 > > > > Forgive my ignorance, but this doesn't seem like a problem that will come up > too > often, so the solution is going to be pretty custom. > > Why would you be changing db settings on the fly? > > Carl K > > > > > -- Waylan Limberg [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: Shared memory across processes
On 6/26/07, Waylan Limberg <[EMAIL PROTECTED]> wrote: > I have not yet used your app (although I had intended to until I read > this) so I assumed you had worked this out already. The thing is, if > each process has to look to a central location to retrieve/update, why > not use the db as that central location? Perhaps the way to go is to > have an option to turn caching on or off. Then, when deployed, the > user could use one of a few pluggable backends (your current > implementation, memcached, etc) to get caching to work. The more I look into it, the more I'm considering exactly that. It would certainly be the easiest way to get it out the door, and any good coder will say not to bother with optimizations (such as caching) until you know whether it's a real concern. For cases where the existing in-process cache won't work, it can just look at the db each time, then see if anybody has any real complaints about the speed of such a solution. >From some basic reading, it seems mod_python should be alone in this problem. FastCGI, for instance, looks like it all runs in a single process, so installations there should be fine. With that in mind, I'm considering using mod_python's mpm_query[1] to see if the current MPM forks (which is where the problem occurs). That way I don't have to add another action to the installation process, and I don't clutter up settings.py with such a special-purpose setting. I'm not sure on that yet, though. As for why I hadn't run into this myself yet, I haven't actually done any work with mod_python until a couple days ago. I've been working entirely with Django's development server, where everything works just fine. Thoughts, anyone? -Gul [1] http://www.modpython.org/live/current/doc-html/pyapi-apmeth.html#l2h-40 --~--~-~--~~~---~--~~ 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: Shared memory across processes
> I have not yet used your app (although I had intended to until I read > this) so I assumed you had worked this out already. Same goes for me, but I try to answer something useful anyway. > The thing is, if > each process has to look to a central location to retrieve/update, why > not use the db as that central location? Or why not use a python-file as "cache"? AFAIK Django already reloads the settings-file if is has changes. So why not use this and put the settings generated from the DB there (or in some file imported in settings.py). A post_save-handler in the settings-module should do the rest... Sorry if this is stupid and I miss some bigger picture here. ;-) Greetings, David Danier --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Request for Model History to be merged into trunk (updated code supplied)
The 'fullhistory' branch has been lying dormant for a few months it seems (at least no commits to the django hosted branch) - so I've recently updated and implemented leftover functionality in a modified version of the branch. It is undoubtedly imperfect, but it should work in common use cases that are checked by the included tests. The embedded docs should shed light on any differences. The code is available at [http://pineapple.binrock.net/django/ modelhistory.tar.bz2] The tar consists of just the contrib subdirectory, should extract directly into django/contrib and 'work out of the box.' It supports accounting on the following operations (through the ChangeLogManager): (1) Creation (2) Mutation (including reverts) (3) Deletion The method signature changed (slightly) to taste: - get_version(obj,rev) -> [Model]/None - get_version_by_date(obj,date) -> QuerySet/list() - get_history(obj,offset=0) -> QuerySet/list() - set_version(obj,rev) -> [Model]/None - restore_version(content_type,obj_id,rev) -> [Model]/None The current code also provides for determining the calling user (the django.contrib.auth.models.User who initiated the model change). This method works (*tilts head*) but is meant more as a placeholder until a better implementation is discussed/implemented. There are a few issues that I think should be considered: (1) it should probably provide some means (if end user-desired) of providing distinct tables for each revisioned object (for performance reasons) (2) although it seems to function properly when embedded directly as django.contrib.modelhistory, I noticed some issues where it appeared that multiple processes were calling the provided dispatcher.connect(...), in effect, doubling (or tripling) the changelog output when installed as an app. With regard to (1), we have syncdb hooks and _log could be autogenerated; however, (1) might be best served when coupled with a distinct subsystem that manages backend-specific logic - i.e., django/ multi-db allowing for a separate archival database, in which case this discuession would require a much broader consensus/design points. Hopefully, these issues can be dealt with quickly, and this (imho) highly useful contrib app can be fast-tracked. As always, feedback(being-put-in-my-place) greatly appreciated. -Thom Linton --~--~-~--~~~---~--~~ 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: Request for Model History to be merged into trunk (updated code supplied)
Hey Thom -- This looks great at first glance -- many, many thanks! However, I'm not going to get much of a chance to review this for inclusion for at least a few weeks, and possibly longer. I'd suggest you set up a Google Code Hosting site for this and keep it up-to-date. That way it can live as a third-party app reguardless of its eventual inclusion into Django. Thanks again, Jacob --~--~-~--~~~---~--~~ 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: Shared memory across processes
On 6/26/07, David Danier <[EMAIL PROTECTED]> wrote: > Or why not use a python-file as "cache"? AFAIK Django already reloads > the settings-file if is has changes. So why not use this and put the > settings generated from the DB there (or in some file imported in > settings.py). A post_save-handler in the settings-module should do the > rest... > Sorry if this is stupid and I miss some bigger picture here. ;-) I could use a file as cache, yes, but what you're dsecribing wouldn't really work well in production environments. To my knowledge, Django reloads itself in its entirety if any loaded modules are changed, not just a single file. Sure, these things will change rarely enough that it might be tolerable, but the goal of the project was to avoid restarting the server, and this method would do exactly that. Additionally, the autoreload option isn't always available depending on your setup. That said, mod_python does provide its own autoreloading import system[1], which could probably be used for this, I suppose. By doing it that way, it would only reload the one file, which should happen pretty quickly. It's definitely an approach I hadn't considered, so I'll add it to the list of options. -Gul [1] http://www.modpython.org/live/mod_python-3.3.1/doc-html/pyapi-apmeth.html#l2h-32 --~--~-~--~~~---~--~~ 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: Shared memory across processes
On 6/26/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > I could use a file as cache, yes, but what you're dsecribing wouldn't > really work well in production environments. To my knowledge, Django > reloads itself in its entirety if any loaded modules are changed, not > just a single file. Sure, these things will change rarely enough that > it might be tolerable, but the goal of the project was to avoid > restarting the server, and this method would do exactly that. > Additionally, the autoreload option isn't always available depending > on your setup. > > That said, mod_python does provide its own autoreloading import > system[1], which could probably be used for this, I suppose. By doing > it that way, it would only reload the one file, which should happen > pretty quickly. It's definitely an approach I hadn't considered, so > I'll add it to the list of options. > But then you need to figure out the autoreload options for any particular web server that might be used. The dev server does autoreloading, but most of the others don't by default. I'd go with the database option. These options aren't going to change too often, so the db's cache (if any) should return the result quick enough, and you know that in *all* circumstances, a db will be present. Of course, that's just my opinion for the colour of this particular bikeshed. Jay P. --~--~-~--~~~---~--~~ 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: Shared memory across processes
Seems to me that this is exactly the problem that Django's cache framework was designed to solve. I don't see a reason to reinvent the wheel for dbsettings... It should be extremely simple to invalidate the cache if/when the setting is changed, and if people are using memcached like all good developers should it'll Just Work. Jacob --~--~-~--~~~---~--~~ 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: Shared memory across processes
Another problem with a file is that you generally have to rewrite the entire file to update just one value. Suppose process A has read the filed, then process B reads the file. Then process A updates value FOO and overwrites the file. Process B then updates value BAR and overwrites the file. The problem is that process B wasn't aware of the changes made by process A, so the new value for FOO is lost. Sure, you could create some file locking mechanism, by why? Databases address those issues and are very good at it. On 6/26/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > > On 6/26/07, David Danier <[EMAIL PROTECTED]> wrote: > > Or why not use a python-file as "cache"? AFAIK Django already reloads > > the settings-file if is has changes. So why not use this and put the > > settings generated from the DB there (or in some file imported in > > settings.py). A post_save-handler in the settings-module should do the > > rest... > > Sorry if this is stupid and I miss some bigger picture here. ;-) > > I could use a file as cache, yes, but what you're dsecribing wouldn't > really work well in production environments. To my knowledge, Django > reloads itself in its entirety if any loaded modules are changed, not > just a single file. Sure, these things will change rarely enough that > it might be tolerable, but the goal of the project was to avoid > restarting the server, and this method would do exactly that. > Additionally, the autoreload option isn't always available depending > on your setup. > > That said, mod_python does provide its own autoreloading import > system[1], which could probably be used for this, I suppose. By doing > it that way, it would only reload the one file, which should happen > pretty quickly. It's definitely an approach I hadn't considered, so > I'll add it to the list of options. > > -Gul > > [1] > http://www.modpython.org/live/mod_python-3.3.1/doc-html/pyapi-apmeth.html#l2h-32 > > > > -- Waylan Limberg [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: Shared memory across processes
On 6/26/07, Jay Parlar <[EMAIL PROTECTED]> wrote: > > That said, mod_python does provide its own autoreloading import > > system[1], which could probably be used for this, I suppose. By doing > > it that way, it would only reload the one file, which should happen > > pretty quickly. It's definitely an approach I hadn't considered, so > > I'll add it to the list of options. > > > > But then you need to figure out the autoreload options for any > particular web server that might be used. The dev server does > autoreloading, but most of the others don't by default. Well, I was in the middle of typing "but mod_python is the only one with the problem!" when I remembered seeing that FastCGI can not only run as prefork, but defaults to it. I expect that would indeed exhibit the same problem, which would, as you mention, render any mod_python fix irrelevant. > I'd go with the database option. These options aren't going to change > too often, so the db's cache (if any) should return the result quick > enough, and you know that in *all* circumstances, a db will be > present. Very true. And if performance does suffer, there are still a few things that could be done to optimize it, but I'll definitely not worry about those unless somebody has a considerable issue with it. -Gul --~--~-~--~~~---~--~~ 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: Shared memory across processes
On 6/26/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > Seems to me that this is exactly the problem that Django's cache > framework was designed to solve. I don't see a reason to reinvent the > wheel for dbsettings... > > It should be extremely simple to invalidate the cache if/when the > setting is changed, and if people are using memcached like all good > developers should it'll Just Work. > > Jacob Except that if people aren't using memcached, but locmem, for example, invalidating the cache only does so for that current process, which would result in the same problem we're currently having. That is, unless I'm reading the code wrong, which is entirely possible. I suppose I could just rely on Django's cache and just put a note in the docs saying to use memcached, db or file, rather than locmem or simple, since those will cause problems. More thinking to do. -Gul --~--~-~--~~~---~--~~ 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: Request for Model History to be merged into trunk (updated code supplied)
Django-modelhistory is now living at [http://code.google.com/p/django- modelhistory/] Regards, Thom On Jun 26, 3:48 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > Hey Thom -- > > This looks great at first glance -- many, many thanks! > > However, I'm not going to get much of a chance to review this for > inclusion for at least a few weeks, and possibly longer. I'd suggest > you set up a Google Code Hosting site for this and keep it up-to-date. > That way it can live as a third-party app reguardless of its eventual > inclusion into Django. > > Thanks again, > > Jacob --~--~-~--~~~---~--~~ 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: Shared memory across processes
On Jun 27, 6:31 am, "Marty Alchin" <[EMAIL PROTECTED]> wrote: > On 6/26/07, Jay Parlar <[EMAIL PROTECTED]> wrote: > > > > That said, mod_python does provide its own autoreloading import > > > system[1], which could probably be used for this, I suppose. By doing > > > it that way, it would only reload the one file, which should happen > > > pretty quickly. It's definitely an approach I hadn't considered, so > > > I'll add it to the list of options. > > > But then you need to figure out the autoreload options for any > > particular web server that might be used. The dev server does > > autoreloading, but most of the others don't by default. > > Well, I was in the middle of typing "but mod_python is the only one > with the problem!" when I remembered seeing that FastCGI can not only > run as prefork, but defaults to it. I expect that would indeed exhibit > the same problem, which would, as you mention, render any mod_python > fix irrelevant. As well as mod_python and fastcgi/scgi solutions you also have mod_wsgi. In 'embedded' mode of mod_wsgi you inherit the process model of the Apache MPM in use. In 'daemon' mode of mod_wsgi you can have prefork or worker like process models. In theory the problem applies also to any WSGI server. At least in the sense that the WSGI specification specifically makes allowance for multi-process as well as multi-thread servers, with WSGI adapters being required to provide values in the WSGI environment indicating what model is being used. One possible shortcoming of WSGI is that you will only get this information the first time a request is received. There is no global concept of a 'wsgi' module where 'multithread' and 'multiprocess' may be queried, although perhaps there should be. For further background reading see: http://www.dscpl.com.au/wiki/ModPython/Articles/TheProcessInterpreterModel http://www.python.org/dev/peps/pep-0333/ Graham --~--~-~--~~~---~--~~ 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: Shared memory across processes
On 6/26/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > Except that if people aren't using memcached, but locmem, for example, > invalidating the cache only does so for that current process, which > would result in the same problem we're currently having. That is, > unless I'm reading the code wrong, which is entirely possible. The docs claim the locmem backend is multi-process. Am I misreading that? -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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: Shared memory across processes
On 6/26/07, James Bennett <[EMAIL PROTECTED]> wrote: > The docs claim the locmem backend is multi-process. Am I misreading that? Hrm, no, you're not misreading it. I hadn't noticed that line before you mentioned it, but I didn't see anything in the code that looked like it handled the multi-process portion. Regardless though, I think Jacob makes the best point so far: Django's cache system is robust enough to handle it if you pick a decent backend. And if there's a need to make the built-in options more robust, we can deal with that when the need arises. And hey there, Graham! It's always interesting to see names on two different lists. -Gul --~--~-~--~~~---~--~~ 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: Request for Model History to be merged into trunk (updated code supplied)
On 6/26/07, Thom Linton <[EMAIL PROTECTED]> wrote: > The method signature changed (slightly) to taste: >- get_version(obj,rev) -> [Model]/None >- get_version_by_date(obj,date) -> QuerySet/list() >- get_history(obj,offset=0) -> QuerySet/list() > >- set_version(obj,rev) -> [Model]/None >- restore_version(content_type,obj_id,rev) -> [Model]/None Is there a particular reason you're returning None instead of just letting DoesNotExist indicate what's going on? I just ask because in other environments, I've had to deal with methods which return None in such cases, and it just seems to lead to headaches down the road. Some programmer somewhere forgets to check if it's None, and next thing you know, you're getting strange NoneType AttributeErrors that are hard to track down to their true source. This is, no doubt, just a personal preference, it just seems like it could be problematic. -Gul --~--~-~--~~~---~--~~ 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: BooleanField and NullBooleanField (#2855 again)
I would have thought it's obvious. Any fields are are not null=True must have a default specified in the model or a value explicitly provided before calling save(). However, I just did a quick double- take and it looks like CharField actually has an implicit default of "" already. If CharField can have an implicit default of '', I don't see why BooleanField can't have an implicit default of False (empty), or why IntegerField can't have an implicit default of 0. Personally, I'd rather vote for the removal of 'empty' defaults from CharField than their addition to BooleanField and IntegerField. If you want a default of False, or 0, or "", just specify those in your model. Why is there an implicit default of "" on CharField anyway? --~--~-~--~~~---~--~~ 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: Django Week in Review -- ATTN: Adrian Holovaty
Great work, Clint! These updates are going to be a lifesaver! --~--~-~--~~~---~--~~ 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: Request for Model History to be merged into trunk (updated code supplied)
On Tue, 2007-06-26 at 19:43 +, Thom Linton wrote: > The 'fullhistory' branch has been lying dormant for a few months it > seems (at least no commits to the django hosted branch) - so I've > recently updated and implemented leftover functionality in a modified > version of the branch. > > It is undoubtedly imperfect, but it should work in common use cases > that are checked by the included tests. The embedded docs should shed > light on any differences. > > The code is available at [http://pineapple.binrock.net/django/ > modelhistory.tar.bz2] > > The tar consists of just the contrib subdirectory, should extract > directly into django/contrib and 'work out of the box.' Following on from Jacob's suggestion to host it externally for a bit, it would be worth adjusting the import paths so that people can use it as a true third-party app, rather than having to modify their Django source. The contrib/ directory is just another directory, so there's nothing special about an app that lives there or somewhere else, *except* that Django own contrib/, so external apps shouldn't scribble in that space (it might well be non-writable, for example). Also, it's been a while since I've read the code and I haven't read your update, but if you are targeting a particular version of Django, it would be worth mentioning that in the docs. I'm mostly thinking that if you are targeting subversion trunk -- which you probably are -- there will be backwards incompatible things that mean it might not work with 0.96, so let people know that up-front. Finally, have a quick search through Trac to see if there any open tickets. I know of #3428, at least, which has some fixes which you might wish to include. (Unfortunately, I'm in a similar boat as Jacob with regards to time availability. I have slightly more Django tasks to do than free time and I don't feel comfortable bumping a major thing up the queue at the moment, since some items have been waiting a while and I want to get them done.) Regards, Malcolm -- A conclusion is the place where you got tired of thinking. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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: Volunteering for "Week in Review" postings
A little late to the party due to my travels to Never-Never land, but... On 6/19/07, Clint Ecker <[EMAIL PROTECTED]> wrote: > I think it would be most prudent to publish these before > noon on Mondays when there are likely to be the most eyeballs. Does > this sound reasonable? If this is your goal, keep in mind that the US is pretty much the last place in the world to experience any given "noon on a Monday". By the time it's Monday noon in the US, it's pretty much Tuesday in my part of the world. So, if you are aiming to put this in front of the world first thing Monday morning, you might want to consider posting on a Sunday afternoon/evening US time. 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: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)
On 6/20/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > Yep. None of the javascript stuff really works right now. The calendar > and picker widgets for date and time fields, for instance, are broken. Sounds like a good opportunity to plug ticket #4418 - widget level support for specifying media (javascript/css) requirements. I haven't gone back to retrofit this into newforms-admin (or even had a chance to look at the new edit-inline stuff), but I'd be interested on any feedback on how the edit-inline changes would affect this approach. 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: Ticket #650 - render_to_response uses Context instead DjangoContext
On 6/26/07, Paul Bowsher <[EMAIL PROTECTED]> wrote: > > render_to_response is a great shortcut, however in my opinion it's let > down by not supporting request. I see this has been discussed a bit on > the ticket, however that's more in respect to replacing the existing > shortcut. Isn't this just the 'direct_to_template' generic view? 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 -~--~~~~--~~--~--~---
