On Dec 5, 11:43 am, Stephen Burrows
wrote:
> I've often longed for a "read-only" concept in ModelForms. For
> example, if I want the "site" field to always have a certain value
> (i.e. the current site) but also want to enforce multiple-column
> uniqueness (i.e. slug/site). I can write it myself,
I've often longed for a "read-only" concept in ModelForms. For
example, if I want the "site" field to always have a certain value
(i.e. the current site) but also want to enforce multiple-column
uniqueness (i.e. slug/site). I can write it myself, but it always
feels like I shouldn't have to. Probab
On Dec 3, 7:18 pm, Carl Meyer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 12/03/2011 02:13 AM, Anssi K ri inen wrote:
>
> > Admin should be fixed [#2259]. Making PK fields non-editable in
> > ModelForms would be good, too. Is it OK to consider the current
> > ModelForm behavior
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/03/2011 02:13 AM, Anssi Kääriäinen wrote:
> Admin should be fixed [#2259]. Making PK fields non-editable in
> ModelForms would be good, too. Is it OK to consider the current
> ModelForm behavior a bug, or will it need a deprecation cycle?
I thin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/03/2011 10:18 AM, Carl Meyer wrote:
> So what about admin users who are currently relying on this behavior as
> a way to clone objects with natural PKs (given that the
> save-and-add-another button is useless with natural PKs unless you can
> exp
On Dec 3, 5:03 am, Carl Meyer wrote:
> Did we gain support for multi-column PK recently and I missed it? Or is
> this just a hypothetical example assuming such support is added in the
> future?
Yes, this is a hypothetical example, inspired by the GSoC work on
multicolumn primary keys [https://git
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/02/2011 07:29 PM, Kääriäinen Anssi wrote:
> At this point this is not the idea. The idea is to just disallow this
> (assuming
> multicolumn PK firstname, lastname):
>
> user = User(firstname = 'Jack', lastname = 'Smith')
> user.save()
> user.fi
"""
On 12/02/2011 06:54 PM, Kääriäinen Anssi wrote:
> I think I will pursuit the immutable PK approach, and see how it
> works (back to square one). BTW are there -1 calls on this approach,
> or the pk change tracking in general?
I haven't been fully following this thread, but I will say that I'm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Anssi,
On 12/02/2011 06:54 PM, Kääriäinen Anssi wrote:
> I think I will pursuit the immutable PK approach, and see how it
> works (back to square one). BTW are there -1 calls on this approach,
> or the pk change tracking in general?
I haven't been
"""
That's really too bad; I was hoping that that approach would work. (Also, I
really hope nobody is using a FileField for a primary key ;) )
Is the problem here that we can't reliably tell whether the data that is going
out to the DB layer has changed? I would think that no matter how the data
On Thu, Dec 1, 2011 at 6:38 PM, Anssi Kääriäinen wrote:
> On Nov 30, 2:26 pm, Kääriäinen Anssi wrote:
>
\> The other way is storing old_pk in model._state, and compare the PK to
> > that when saving. If changed, error. This would work best if there was a
> > NoneMarker object for the cases where
"""
Now for the funny part of this. I suspected that __setattr__ would
make init slower. But using a little trick, __init__ is now actually
almost 30% faster for a 10 field model. The trick is checking if
setattr needs to be called. It needs to be called if the user has
defined __setattr__ for some
On Dec 2, 4:38 am, Anssi Kääriäinen wrote:
> - Have the "I'm mutable" flag for fields. I don't know if this is
> workable from performance standpoint. In practice the implementation
> could be descriptor based for in-place mutable fields.
I implemented POC of this and __setattr__ based way of t
On 2 December 2011 15:38, Anssi Kääriäinen wrote:
> The bad part about do-nothing is that:
> - I really do not like the API of .save() not changing the PK, but
> instead duplicating the object. Maybe I am alone here.
Definitely not.
Cheers,
mwh
--
You received this message because you are sub
On Nov 30, 2:26 pm, Kääriäinen Anssi wrote:
> I can think of two basic approaches to this: define a __setattr__ for Models,
> and check if the pk is set after fetch from DB. This has at least three
> problems:
> 1. It is likely that users have custom __setattr__ methods that do not use
> super().
Settings pk as None is recommended method of model cloning, as per:
https://docs.djangoproject.com/en/dev/topics/db/queries/#copying-model-instances
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
h
On 30/11/11 21:19, Ian Clelland wrote:
> I would consider Django 1.4+ to fall under the "new programs" umbrella :)
Agreed. Thanks for all that research. Since we currently don't support
nullable PKs (implicit in our 'pk is None' idiom), there is no need to
do so going forward, and that allows a s
"""
/me runs off to go correct Wikipedia ;)
I checked the Wikipedia article on Primary Key first, and didn't see that, but
I did note this:
A table can have at most one primary key, but more than one unique key. A
primary key is a combination of columns which uniquely specify a row. It is a
sp
On Wed, Nov 30, 2011 at 1:15 PM, Ian Clelland wrote:
> On Wed, Nov 30, 2011 at 12:40 PM, Kääriäinen Anssi <
> anssi.kaariai...@thl.fi> wrote:
>
>> """
>> Is this referring exclusively to natural, or user-specified primary key
>> columns? Despite Luke's reference to nullable primary keys (are thes
On Wed, Nov 30, 2011 at 12:40 PM, Kääriäinen Anssi
wrote:
>
> """
> Is this referring exclusively to natural, or user-specified primary key
> columns? Despite Luke's reference to nullable primary keys (are these even
> allowed by SQL?), a common idiom for copying objects is this:
> """
>
> Not all
"""
Is this referring exclusively to natural, or user-specified primary key
columns? Despite Luke's reference to nullable primary keys (are these even
allowed by SQL?), a common idiom for copying objects is this:
"""
Not allowed by SQL specification, but many databases do allow them (source
wi
On Wed, Nov 30, 2011 at 4:26 AM, Kääriäinen Anssi
wrote:
> """
> > The reason for doing the deprecation now is that it would be nice that
> > this behavior is already removed when multicolumn primary keys are
> > introduced into Django.
> >
> > There is a ticket related to this: #2259.
>
> Here is
"""
> The reason for doing the deprecation now is that it would be nice that
> this behavior is already removed when multicolumn primary keys are
> introduced into Django.
>
> There is a ticket related to this: #2259.
Here is another that could be helped by this change, depending on
implementation
On 30/11/11 07:13, Anssi Kääriäinen wrote:
> The reason for doing the deprecation now is that it would be nice that
> this behavior is already removed when multicolumn primary keys are
> introduced into Django.
>
> There is a ticket related to this: #2259.
Here is another that could be helped by
I am suggesting the following PK change behavior will be deprecated in
1.4. The problem is this:
class SomeModel:
name = models.CharField(max_length=20, primary_key=True)
s = SomeModel(name='foo')
s.save()
s.name='bar'
s.save()
At this point you end up with both 'foo' and 'bar' objects in the
25 matches
Mail list logo
