#8898 is a simple bug fix with tests for DateTime fields with
required=False, which currently fail to validate in the admin because
the `required` validation is being bypassed when using
SplitDateTimeWidget with DateTimeField (which seems questionable to
begin with).
I'd set it to ready for check
Hey Jessie --
See ticket #6791. It's got a well-written, working implementation; it
didn't make it into 1.0 because of time constraints. It'll almost
certainly make it into 1.1.
Jacob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to t
I think it would be useful to include a session backend with Django
that stores session data in the cache and falls back to the database
if the session isn't in the cache. It's trivial to write your own
(mine is about 30 lines of code), but it seems like such a common use
case that it should just
Hey Alex,
On the trac ticket, I mentioned that my motivating reason for adding
specifying default-lazy fields in the Field definition (i.e., without
having to specify them on every query set) is the implicit queries
that Django creates for foreign key lookups (e.g., item =
obj.relateditem causes
I think the sensible solution is to have what the ticket originally
suggested, a queryset/manager method to control whether a field is
lazy loading, and yes, that can be implemented without patching
django, you can, of course, make this the default by overiding the
default manager.
On Oct 14, 12:
On Tue, Oct 14, 2008 at 12:34 PM, Jesse Young <[EMAIL PROTECTED]> wrote:
> A LazyTextField that manages a dynamic model behind the scenes sounds
> like a neat idea. That would certainly make the Django side of this
> easier to manage. (But of course I have a slight bias towards code
> that exists
> And LazyTextField could create the associated model behind the scenes,
> set up a descriptor for loading its contents only when necessary,
> cache those contents so they only get queried once, etc. And all this
> without a single patch to Django's core and without you having to
> manually mainta
Moving discussion from http://code.djangoproject.com/ticket/5420.
To summarize, I patched my local version of Django by adding a boolean
'lazy' parameter to the Field constructor, e.g.
models.TextField(lazy=True), which determines whether Django loads
that field by default on select queries, and
I won't pretend to know the whole story here, but I will take issue
with some of your points. I'll leave others to people who have history
on the subject.
On Tue, Oct 14, 2008 at 3:14 AM, Jesse Young <[EMAIL PROTECTED]> wrote:
> * If you split them out, you have to manually create one model every
Hi,
I took a great email from Gary Wilson to get me started on the status structure.
Some of the core design decisions were finalised by Jacob, Malcolm
(please scream if I have misunderstood or don't remember things
correctly) and me at DjangoCon.
Honza Král
E-Mail: [EMAIL PROTECTED]
ICQ#: 1074
On 13 oct, 17:15, Brian Beck <[EMAIL PROTECTED]> wrote:
> On Oct 13, 8:38 am, "Mike Scott" <[EMAIL PROTECTED]> wrote:
>
> > Secondly this question has been asked, and solved many times. If you search
> > through the django-users archives I'm sure you'll find plenty of solutions.
> > There are solu
11 matches
Mail list logo
