Oops looks like I got distracted and hit send mid-thought. That last
part is supposed to be:
Obviously this function could get very complicated for a heavily
sharded setup, but sharding is complicated by definition, so where
that complexity goes isn't necessarily relevant. Letting this logic
So, I'm still learning my way around the deeper parts of the codebase,
but at first glance the "function pointed to from settings.py"
approach seems best. This way, the connection management is completely
opaque to the model. If that function isn't defined, it can just fall
back to the default
On Sep 30, 12:29 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> I've been thinking through, with a couple of different people, how we
> can support extra lookup types on fields and so I'm going to reserve
> judgement on this particular implementation until I have some thoughts
> in order on
On Mon, 2008-09-29 at 18:37 -0700, Ross Poulton wrote:
> When working with any calendar or event tracking information in Django
> it would be useful to be able to filter for items based on day of
> week:
>
> Event.objects.filter(event_date__week_day=1) # objects from any
> month/year/date,
My latest patch added to ticket # 7672 works against the latest SVN
checkout (r9097).
All it needs in my opinion is a decision on the best way to handle
Oracle dates, and testing against Oracle.
Ross
--~--~-~--~~~---~--~~
You received this message because you are
When working with any calendar or event tracking information in Django
it would be useful to be able to filter for items based on day of
week:
Event.objects.filter(event_date__week_day=1) # objects from any
month/year/date, provided it's a Sunday
will generate:
SELECT ... WHERE
On Mon, 2008-09-29 at 10:37 -0700, bo wrote:
>
> This little issue is really hard to replicate .. i've yet to find out
> how to programatically do it because it certainly revolves around a
> threading, object caching, and the Yield in Query.py (iteritems).
>
> I just wanted to post this here
On Mon, 2008-09-29 at 03:25 -0700, Richard Davies wrote:
[...]
> So, do we agree that it makes sense for me to take the current 3460
> patch and complete it in the manner which I described in
> http://groups.google.com/group/django-developers/msg/48500109ac5e514d
> ?
I'd be amazed (and fairly
After miserably failing at making it possible to use a field
with 10k choices, I've decided to take a new approach in the admin.
Right now I'm writing up a widget which would take the m2m field (for
raw_admin_fields) and output it just as it would a foreign key, except
one input per line. This
Hi All, I posted this earlier in Django-users, but then I thought
this might be a better place.
I've started working on a SelectTimeWidget that is very similar to the
SelectDateWidget in django.forms.extras.
http://dpaste.com/hold/81196/
I'm also pondering the creation of a
On Mon, Sep 29, 2008 at 1:22 PM, mihasya <[EMAIL PROTECTED]> wrote:
> Hey, is anybody actually tackling the database scale stuff Cal "joked"
> about in his keynote? I'd like to work on it, but don't want to spin
> my wheels if the core team is already working on it.
If you'll search the archives
Hey, is anybody actually tackling the database scale stuff Cal "joked"
about in his keynote? I'd like to work on it, but don't want to spin
my wheels if the core team is already working on it.
Mike.
--~--~-~--~~~---~--~~
You received this message because you are
Brian Beck wrote:
> I think your model_field helper being built-in (short for
> x._meta.get_field(y).formfield(**params), which is not very pretty)
> would be the best solution here. In my experience, customizing just
> the widget for a model field is just as common as changing just the
> label,
This little issue is really hard to replicate .. i've yet to find out
how to programatically do it because it certainly revolves around a
threading, object caching, and the Yield in Query.py (iteritems).
I just wanted to post this here to see if anyone, with more experience
then i, knows howto
Hi folks --
I've created the 1.0.X branch
(http://code.djangoproject.com/svn/django/branches/releases/1.0.X),
which means the trunk is now open for features. Please read
http://docs.djangoproject.com/en/dev/internals/release-process/ for
more information about what this branch is. For the
SmileyChris wrote:
> I do feel like it leads to slippery slope though. LikeMichael said,
> "why stop at widgets?" I often need to change labels and help text
> too.
Full customization already can be done by specifying fields directly in
a form class. In my experience widgets are just very
On Sep 29, 11:40 pm, Julien Phalip <[EMAIL PROTECTED]> wrote:
> On Sep 29, 10:46 pm, zvoase <[EMAIL PROTECTED]> wrote:
>
> > Why not do something like this:
>
> > class MyForm(forms.ModelForm):
> > class Meta:
> > fields = {
> > 'text':
On Sep 29, 10:46 pm, zvoase <[EMAIL PROTECTED]> wrote:
> Why not do something like this:
>
> class MyForm(forms.ModelForm):
> class Meta:
> fields = {
> 'text': forms.CharField(widget=forms.Textarea(), ...),
> 'other_field': None,
> }
This syntax would
I understand the motivation for this, and support the idea, but I
think the implementation is a little repetitive:
class MyForm(forms.ModelForm):
class Meta:
fields = # LIST OF FIELDS
widgets = # DICT OF FIELD NAMES : WIDGETS
Why not do something like this:
class
I'm going to make one final post in this thread, since we didn't quite
reach a conclusion.
Malcolm Tredinnick wrote:
> As I mentioned to Collin at the code sprint in Portland, I think it'd be
> a good idea to make sure we expose the ability to turn on auto-commit,
> but I don't really like
Bah, it was just prototype code but point taken ;)
I do feel like it leads to slippery slope though. LikeMichael said,
"why stop at widgets?" I often need to change labels and help text
too.
On Sep 29, 8:56 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> SmileyChris wrote:
> > I've always just
SmileyChris wrote:
> I've always just done this by doing:
>
> MyForm(ModelForm)
> model = MyModel
> def __init__(self, *args, **kwargs):
> self.fields['name'].widget = Textarea() # or whatever
You've forgot to call `super` :-). I know that it's only an example but
it adds
On Sep 28, 5:02 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Short version: model-aware validation is being worked on. We didn't get
> it finished for 1.0, but it's still ongoing work.
Great! Judging by the activity this is tracked in #6845 so I included
a note and a reference in the
23 matches
Mail list logo
