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
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
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
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) ->
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
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
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
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
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
>
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
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
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
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,
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
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
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
> 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
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
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,
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]
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
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
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
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
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
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
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
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
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
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
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
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
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)
> ...
>
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
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
I have a model class like this:
class PagesInternal(models.Model):
name = models.CharField(primary_key=True, maxlength=150)
...
And my names (the primary
36 matches
Mail list logo
