Yeah, I see where you're coming from, I'll write up some code based on
this, because I think I follow what you're saying, but did a poor job
describing my thoughts, hopefully code will speak louder than words.
Alex
On Dec 11, 11:29 pm, Malcolm Tredinnick
wrote:
> On Thu, 2008-12-11 at 19:33 -08
On Thu, 2008-12-11 at 19:33 -0800, alex.gay...@gmail.com wrote:
> If it's preferable to pass in a function, (field.clean
> (self.add_warning))
*facepalm*
You aren't explaining what problems you're trying to solve, but just
popping up alternate options. I keep trying to lay out my assumptions
an
If it's preferable to pass in a function, (field.clean
(self.add_warning)) it can be written that way(using either
introspection or trying and catching the type error), I could have it
do that.
To be clear though, it wasn't using thread locals anywhere, it was
simply keying the dictionary on the
On Thu, 2008-12-11 at 19:16 -0800, alex.gay...@gmail.com wrote:
> Right, but if the warn() function is going to be some sort of global
> (as it is now)
> it needs to have some way to store the warnings in the
> intermediary that is thread safe.
So don't make it a global. I really think you're a
Right, but if the warn() function is going to be some sort of global
(as it is now), it needs to have some way to store the warnings in the
intermediary that is thread safe.
Alex
On Dec 11, 10:14 pm, Malcolm Tredinnick
wrote:
> On Thu, 2008-12-11 at 19:10 -0800, alex.gay...@gmail.com wrote:
> >
On Thu, 2008-12-11 at 19:10 -0800, alex.gay...@gmail.com wrote:
> Ok, so basically when someone calls warn() the warning class stores it
> internally in a dictionary(keyed by thread id) in a list of items,
Huh?!
These are warnings raised during form cleaning and normalisation. The
thread id doe
Ok, so basically when someone calls warn() the warning class stores it
internally in a dictionary(keyed by thread id) in a list of items,
then after each field is processed the full_clean() would get all the
warnings out of the dictionary, put them in the _warnings dictionary
inside itself, and re
Thank you for the quick feedback! I like the mixin analogy.
--~--~-~--~~~---~--~~
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 unsubsc
On Thu, 2008-12-11 at 18:46 -0800, alex.gay...@gmail.com wrote:
> On Dec 11, 9:08 pm, Malcolm Tredinnick
> wrote:
> > On Tue, 2008-12-09 at 13:49 -0800, alex.gay...@gmail.com wrote:
> > > Over the past few days I've been putting together an implementation of
> > > ticket 23[1]. I realise this i
On Thu, 2008-12-11 at 18:42 -0800, SliceOf314 wrote:
> I was just wondering why fields.RelatedField doesn't subclass
> models.Field?
Most likely just historical reasons.
> The comment for RelatedField is that it's a hack, and from what I can
> see RelatedField doesn't override any of Field's fu
On Dec 11, 9:08 pm, Malcolm Tredinnick
wrote:
> On Tue, 2008-12-09 at 13:49 -0800, alex.gay...@gmail.com wrote:
> > Over the past few days I've been putting together an implementation of
> > ticket 23[1]. I realise this isn't on the 1.1 features list, but I'd
> > still like to solicit any though
I was just wondering why fields.RelatedField doesn't subclass
models.Field?
The comment for RelatedField is that it's a hack, and from what I can
see RelatedField doesn't override any of Field's functionatliy.
This way, fields.ManyToMany and fields.ForeignKey wouldn't have to use
multiple inheri
On Tue, 2008-12-09 at 13:49 -0800, alex.gay...@gmail.com wrote:
> Over the past few days I've been putting together an implementation of
> ticket 23[1]. I realise this isn't on the 1.1 features list, but I'd
> still like to solicit any thoughts people have. Right now the API is
> that in any fo
On Thu, Dec 11, 2008 at 7:06 PM, Simon Litchfield wrote:
> +1. Definitely need some kind of cascade=False option somewhere. I'd
> argue it should be the default. I have some production horror stories
> which I'm sure I don't need to share.
Keep in mind there is some prior art here which may be u
+1. Definitely need some kind of cascade=False option somewhere. I'd
argue it should be the default. I have some production horror stories
which I'm sure I don't need to share.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
I'm not sure, but this ticket
http://code.djangoproject.com/ticket/8168
"Pre Prepare For Delete" signal (i.e. do things BEFORE delete() tries
to find all the relationships). Would be able to do all the custom
stuff you'd want.
"null out others", "bulk purges in custom queries", etc, etc .. i'd
On Thu, Dec 11, 2008 at 12:36 PM, AcidTonic wrote:
>
> I hear from them that this design should
> have no issues and they went further to question me how I am running
> into problems All they wanted to see were queries and he said
> rewrite it Then i informed him about the ORM and at that
On Thu, Dec 11, 2008 at 12:06 PM, sed...@gmail.com wrote:
...
> As of r8165 of Django (post qs-refactor), model_instance.delete() does
> *not* null out instances with nullable foreign keys that point to the
> about-to-be deleted instance. It deletes them instead. We have a
> special field calle
On Dec 11, 6:36 am, "Jeremy Dunck" wrote:
> I'd like to make sure I understand what we're talking about here.
>
> model_instance.delete() nulls any instances with nullable FKs to the
> deleted instance, right?
>
> The problem AFAICS, is that QuerySet.delete is not so careful, and
> deletes all FK
Trust me, my DBAs have been all over this problem for the past week.
>From custom pl code, to a switch to oracle with more custom code, my
DBAs are literally laughing at the performance of django
We already use a custom cursor to create the IP objects after the
subnet is created because even
On Thu, Dec 11, 2008 at 10:49 AM, oggie rob <[EMAIL PROTECTED]> wrote:
>
> On Dec 10, 6:25 am, AcidTonic <[EMAIL PROTECTED]> wrote:
>> I'm building an application to track IP addresses on many corporate
>> networks with a single subnet having around 65535 rows for IP
>> addresses. Now this app
On Dec 10, 6:25 am, AcidTonic <[EMAIL PROTECTED]> wrote:
> I'm building an application to track IP addresses on many corporate
> networks with a single subnet having around 65535 rows for IP
> addresses. Now this app has thousands of those subnets which means
> I have millions of rows for IP a
I believe any kind of delete will also clobber any models linked to or
from the object getting deleted.
One work around was to implement delete() on the model which nulls the
relationships first. That works except querysets with more than
one instance will NOT call the custom delete() method
Couldnt we use the new Update() method on the queryset to NULL out the
relationships prior to the bulk delete?
At least that method would still apply in bulk vs 1by1 correct? Of
course it wouldnt work when null isnt allowed but thats not the case
for my application.
Or could we add a flag to del
On Wed, Dec 10, 2008 at 3:04 PM, David Cramer <[EMAIL PROTECTED]> wrote:
>
> To be perfectly honest, I'm +1 on a solution. I didn't realize this
> was happening either.
>
> Time to monkey-patch QuerySet's delete() method :)
>
> (I'm also a bit curious as to how its handling cascades in MySQL when
25 matches
Mail list logo
