Thanks Jacob! Greatly appreciated :)
Le mardi 9 juillet 2013 19:04:26 UTC-4, Jacob Kaplan-Moss a écrit :
>
> Hey Michael -
>
> We don't have a schedule for 1.5.2 at the moment, but I'll take a look and
> see if I can get a release out sometime soon. No promises, but I'll do my
> best.
>
> Jacob
On 11 juil. 2013, at 05:46, cmawebs...@gmail.com wrote:
> What do your __unicode__/__str__ methods look like? Is this a bad idea?
In addition to the previous answers, I find it important to have an unambiguous
__unicode__ / __str__, and name isn't necessarily unique.
--
Aymeric.
--
You recei
It's less efficient because of the extra table but that's pretty much the only
option when you need a FK on a model that you can't edit. GFK are not exactly
efficient either, yet most will agree that it's sometime the best option to a
given problem.
I agree that the distinction between FK and O
Luke beat me to it...
We have a couple of abstract models which will fall through a small list of
field names, trying to guess a useful default for __str__ ... but it makes
me feel dirty every time I see it.
Beyond "blessing" a particular (set of?) field names as default str
names... this also ad
What makes “name” special. Why not “label”, “title”, “code”, or any number of
other things that people use internally?
It also seems like you could solve this very easily by creating a stub model:
from django.db import models
class MyModel(models.Model):
class Meta:
Hi All,
Have you ever quickly set up a model, ran syncdb, and added a few sample
objects in the admin to only see a bunch of "MyModel object"s in the
changelist? I always forget to add a __unicode__()/__str__() method on my
models.
I ran "git grep -1 __unicode__" on some of my django projects
On 07/10/2013 05:40 PM, Carl Meyer wrote:
>> I'm not sure I completely agree with Carl that is breaks correspondence
>> -- after all, m2m fields don't correlate to a field, either. However, in
>> the absence of a built-in migrations framework, I suspect a O2M field
>> would be a pretty efficient fo
Hi Russ,
On 07/10/2013 05:33 PM, Russell Keith-Magee wrote:
> On Wed, Jul 10, 2013 at 4:20 PM, Curtis Maloney
> mailto:cur...@acommoncreative.com>> wrote:
>
> I've seen enough people in #django suffering because they need a
> FKey on a table they simply can't alter -- be it because it's i
On Wed, Jul 10, 2013 at 4:20 PM, Curtis Maloney
wrote:
> I've seen enough people in #django suffering because they need a FKey on a
> table they simply can't alter -- be it because it's in a 3rd party app, or
> simply a table their DBA won't permit them to alter, or what have you.
>
> In the end t
I've seen enough people in #django suffering because they need a FKey on a
table they simply can't alter -- be it because it's in a 3rd party app, or
simply a table their DBA won't permit them to alter, or what have you.
In the end they wind up having to create the equivalent of a m2m through
t
I totally agree that we can't have a field on one model that modifies the
underlying table of another model, especially with migrations in mind.
That said, I see value in a OneToManyField backed by a M2M with a unique
constraint on one side. This is particularly useful when you don't want to
mo
Hi Oracle users,
As you may be aware, Oracle 12 was released last month, and Django 1.6
declares Python 3 fully supported. As you may also be aware, Django currently
cannot be tested with Oracle 12 [1] or with earlier Oracle under Python 3 [2],
so these two must be declared unsupported for the
Sometime the answers can be a bit harsh and multiple people reply immediately,
which probably gives the impression of being scolded.
Maybe we could have a template with careful wording that we use every time.
We could also forward the message to django-users like a moderator would do on
a forum
13 matches
Mail list logo
