Oh, I guess Marten never got around to sending an updated pull request with
that commit.
I don't know of any plans for work on virtual fields.
On Friday, July 24, 2015 at 8:03:59 PM UTC-4, Aron Podrigal wrote:
>
> What was the approach Loic has planned? As Marten had an implementation
> here [
What was the approach Loic has planned? As Marten had an implementation
here [1] just without the locking functionality.
Is all the work related to virtual fields done yet?
[1]
https://github.com/knbk/django/commit/7ac5b58587ea2a153766d1601965734731609cdf
On Jul 24, 2015 7:44 PM, "Tim Graham" wr
Loic indicated the latest approach isn't ideal and said he might work on
the issue.
https://github.com/django/django/pull/4184
On Friday, July 24, 2015 at 6:59:56 PM UTC-4, Aron Podrigal wrote:
>
> Bumping up on this again, what are the plans for moving this ahead.
--
You received this messag
Bumping up on this again, what are the plans for moving this ahead.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to djang
Hi Loïc,
The implementation itself no longer depends on locks. I wish it was as
simple as form fields, but the idea is the same. The first commit
(https://github.com/knbk/django/commit/7ac5b58587ea2a153766d1601965734731609cdf)
in fact leaves out the lock feature. It's still an extra option in
Hi Marten,
As mentioned in my previous email I don't recommend an implementation based on
locks.
Please look at how Form and ModelForm support inheritance and shadowing without
it.
--
Loïc
> On Feb 16, 2015, at 21:35, Marten Kenbeek wrote:
>
> Okay, as things were getting more and more com
Okay, as things were getting more and more complicated I sat down for a
while to get back to the essence of this patch. The result [1] is much,
much cleaner and works perfectly. I'll start working on documentation as
well.
[1] https://github.com/knbk/django/tree/ticket_24305_alternative
Op vri
Hi Loïc,
Thanks for the response. I will change my code to generate errors in the
case of abstract fields shadowing concrete fields.
At the moment, the locking mechanism of fields is pretty much the core of
this patch. It is explicitly set to `True` when fields are added to a
concrete model,
Hi Marten,
Sorry for the late response, it's been a busy week. Thanks for working on this,
I'll try to have a look at your branch this weekend.
In the meantime I'll leave some comments below.
> On Feb 12, 2015, at 22:43, Marten Kenbeek wrote:
>
> Current status:
> • Models in general se
Current status:
- Models in general seem to be working.
- Trying to override a concrete (or explicitly locked) field with an
abstract field will keep the concrete field, but not raise any errors. This
occurs when inheriting from (AbstractBase, ConcreteBase).
- I might still ch
Hi Aron,
With option 3, this would work:
class Cousin(models.Model):
child = models.ForeignKey(Child, allow_override=True)
but it would raise an error without `allow_override`.
I think my question really is: should we treat reverse relations as
first-class fields, or not? If we do, 1) wou
Why should this be treated differently than the general behavior when
realted_names clash when you have more than one foreign key to the same
model? So as one would normally do
set the related_name explicitly to some other value.
setting the field to None is just the way of removing a field and h
I'd like some additional opinions on the following:
Say you have the following classes:
class Parent(models.Model):
cousin_set = models.CharField(max_length=100)
class Meta:
abstract = True
class Child(Parent):
pass
class Cousin(models.Model):
child = models.ForeignKey(
The general reaction seems to be a yes if we can work out the kinks, so I
went ahead and created a ticket: https://code.djangoproject.com/ticket/24305
@Aron That's a good question. One option would be to lock certain fields,
so that they can't be changed if they are an integral part of the model
That's what we've done in Django 1.7 for Form/ModelForm (#19617, #8620), and I
completely agree that it should be possible to shadow fields from abstract
models. The docs even suggest that this may be possible in the future; quoting
the relevant section: "this [shadowing] is not permitted for at
Hi,
I also think so, that overriding a field should not need any special protection.
But how would you deal with inherited managers on the class that might refer to
some overridden field that has changed?
--
You received this message because you are subscribed to the Google Groups
"Django dev
Hi Russ,
I can see your point on accidentally overriding fields, though I'm not sure
I agree. In any other case, such as normal attributes and methods, there is
no safety net for overriding attributes either. Any model that would be
affected by this change would also raise an error on import wi
Hi Marten,
I can understand the motivation, and the approach you've taken makes sense.
It definitely strikes me as a much better alternative to tickets like
#24288 than a setting.
https://code.djangoproject.com/ticket/24288
The DRY issue isn't a huge problem for me - it's certainly ungainly to n
18 matches
Mail list logo
