On Mon, Dec 15, 2008 at 5:51 AM, Alex Rades wrote:
>
> Hi,
> my understanding about custom managers is that if you want to define a
> custom manager, you also HAVE to remember to define the "objects"
> manager first, otherwise some parts of django (eg. admin) will not
> work.
>
What does "will n
Hi,
I've been attempting to keep this ticket inline with trunk for quite a
while and it would be useful to get some feedback on it, or start up a
discussion as to how it can move forward. Russell mentioned a while
ago that it could integrate with #4656. Is that still possible?
Thanks,
Da
On Mon, Dec 15, 2008 at 3:12 PM, Karen Tracey wrote:
> On Mon, Dec 15, 2008 at 5:51 AM, Alex Rades wrote:
>>
>> Hi,
>> my understanding about custom managers is that if you want to define a
>> custom manager, you also HAVE to remember to define the "objects"
>> manager first, otherwise some part
Hi,
my understanding about custom managers is that if you want to define a
custom manager, you also HAVE to remember to define the "objects"
manager first, otherwise some parts of django (eg. admin) will not
work.
I find this suboptimal.
I think that "objects" should always be the default manage
Hi,
While working on the new backend support for DB2, I found that in
CREATE TABLE DDL generation, it contains some non-standard SQL syntax.
Here is one example of model.
class User(models.Model):
first_name = models.CharField(max_length=20, null=False)
last_name = models.CharField(max_
See also http://code.djangoproject.com/ticket/9676
On Dec 15, 12:51 pm, "Alex Rades" wrote:
> Hi,
> my understanding about custom managers is that if you want to define a
> custom manager, you also HAVE to remember to define the "objects"
> manager first, otherwise some parts of django (eg. admi
On Mon, 2008-12-15 at 09:12 -0500, Karen Tracey wrote:
> I'd think it unlikely at this point a change would be made that would
> prohibit having a field named 'objects'; the time for such a
> backwards-incompatible change was pre 1.0, if ever. If no one pre-1.0
> found the exisitng behavior troub
Well the reason passing in self is more work is because when someone
does add_warning() they have to know what the name of the field is in
form, while this isn't a problem for clean_ methods, it is
for clean() methods on the fields themselves, while this could be
worked around by an attribute on t
I like the `objects` convention as well as explict default manager
declarations.
I proposed both in
http://groups.google.at/group/django-developers/browse_thread/thread/3e1a668ac84328b6/ce36cbe46276d807
.
Advertisement:
My radical "solution" is to never modify the initial QueryS
I'd like to propose the addition of some useful (and common) fields in
the django core. Things like a JSONFied, YAMLField, HTMLField?,
UUIDField, etc.
A lot of these seem like common things people use, and while many
examples are out there, it'd be nice to simply include these in core
so there's
I'd much rather see a contrib app for these. E.g.::
from django.contrib.datafields import fields as datafields
class MyModel(models.Model):
my_yaml = datafields.YAMLField()
...
and any refactoring that's necessary to facilitate this cleaning should be
dealt with. (And I thin
Ya core/contrib (same thing to me).
My biggest issue with custom fields at the moment is the fact that the
hooks aren't really the best. JSONField/etc have to use ugly signals
to allow any data-type to be used.
On Dec 15, 4:12 pm, "Mike Axiak" wrote:
> I'd much rather see a contrib app for thes
On Mon, Dec 15, 2008 at 4:23 AM, Ambrish Bhargava
wrote:
> Hi,
>
> While working on the new backend support for DB2, I found that in
> CREATE TABLE DDL generation, it contains some non-standard SQL syntax.
>
> Here is one example of model.
>
> class User(models.Model):
>first_name = models.Ch
On Wed, Dec 3, 2008 at 8:14 AM, Luke Plant wrote:
> == Conclusion ==
>
> At the moment, once you've factored everything in, I think 'view
> middleware' + template tag is the way to go, with some more custom
> solution for login CSRF. The SafeForm ends up having an unwieldly
> API, which means it
Make app.
Post on Google Code (or other site)
Profit!
:)
These shouldn't need to be in core to be used.
--
Collin Grady
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this g
On Tue, Dec 16, 2008 at 7:07 AM, David Cramer wrote:
>
> I'd like to propose the addition of some useful (and common) fields in
> the django core. Things like a JSONFied, YAMLField, HTMLField?,
> UUIDField, etc.
>
> A lot of these seem like common things people use, and while many
> examples are
On Mon, 2008-12-15 at 14:07 -0800, David Cramer wrote:
> I'd like to propose the addition of some useful (and common) fields in
> the django core. Things like a JSONFied, YAMLField, HTMLField?,
> UUIDField, etc.
>
> A lot of these seem like common things people use, and while many
> examples are
17 matches
Mail list logo
