Odp: Re: model fields options

[Mateusz Harasymczuk]

In my opinion Meta class may contain this kind of information, and it would 
simplify the process of designing models.
Especially handling fields which contains a lots of data inserted via 
arguments.

However, I think that the Meta class properties should be an alias or a 
handy shortcut, not one and only one way of setting those options.

-- 
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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: model fields options

[Julien Phalip]

On May 7, 2:21 am, Alex Gaynor  wrote:
> Sounds like a bad idea to me.  unique_together doesn't exist on a specific
> field precisely because it isn't an option for any specific fields, it's for
> a set of fields.  All the other options belond to specific fields.

I agree in principle, however I've recently come across a use case
where being able to *override* an individual field's options (in my
case 'unique') with a simple API from the Model's Meta options would
have been nice: http://code.djangoproject.com/ticket/15953

I don't know enough about the ORM to predict if that sort of things
could have bad side effects. What do you think?

Julien

-- 
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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: model fields options

[Javier Guerra Giraldez]

On Fri, May 6, 2011 at 12:22 PM, legutierr  wrote:
> Why is help_text part of the field
> definition?  This is a ui-specific thing--what does it have to do with
> the database?  All abstractions are leaky, sure, but this seems
> inappropriate.  The same thing goes for editable, error_messages:
> these options are not part of the ORM, they are parts of the forms
> subsystem that have somehow ended up in the ORM.  Why should the ORM
> know anything about forms, or any other part of Django for that
> matter?

they're UI things, but forms aren't the only UI imaginable.

and, they're UI things that belong to the field.  not the database
field, but the model field.

-- 
Javier

-- 
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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: model fields options

[Carl Meyer]

Hi Eduardo,

On 05/06/2011 12:22 PM, legutierr wrote:
> You're probably right about this, but (while we are on the subject)
> aren't there some things that shouldn't be part of the model field
> options that currently are?  Why is help_text part of the field
> definition?  This is a ui-specific thing--what does it have to do with
> the database?  All abstractions are leaky, sure, but this seems
> inappropriate.  The same thing goes for editable, error_messages:
> these options are not part of the ORM, they are parts of the forms
> subsystem that have somehow ended up in the ORM.  Why should the ORM
> know anything about forms, or any other part of Django for that
> matter?

I think error_messages may actually belong in the ORM now, since
model-validation. Totally agreed that editable and help_text don't
belong there - I think the fact that they're still there is just a
matter of historical inertia, and that nobody's been sufficiently
motivated to deal with the backwards-compatibility difficulties to
change it.

Carl

-- 
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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: model fields options

[Mikhail Korobov]

Not exactly related, but this is how help_text (and other field options) can 
be moved out from the field definition without patching 
django: http://djangosnippets.org/snippets/2180/

-- 
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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: model fields options

[legutierr]

> Sounds like a bad idea to me.  unique_together doesn't exist on a specific
> field precisely because it isn't an option for any specific fields, it's for
> a set of fields.  All the other options belond to specific fields.
>
> Alex

You're probably right about this, but (while we are on the subject)
aren't there some things that shouldn't be part of the model field
options that currently are?  Why is help_text part of the field
definition?  This is a ui-specific thing--what does it have to do with
the database?  All abstractions are leaky, sure, but this seems
inappropriate.  The same thing goes for editable, error_messages:
these options are not part of the ORM, they are parts of the forms
subsystem that have somehow ended up in the ORM.  Why should the ORM
know anything about forms, or any other part of Django for that
matter?

Eduardo

-- 
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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: model fields options

[Alex Gaynor]

On Fri, May 6, 2011 at 12:08 PM, Mateusz Harasymczuk <m...@harasymczuk.pl>wrote:

> I had an idea.
>
> To move model fields options, such as:
> - blank=BOOL
> - null=BOOL
> - auto_add=BOOL
> - auto_add_now=BOOL
> - db_index=BOOL
>
> and others boolean options to Meta class of this model.
>
> It would make model fields more readable and human friendly.
> However I am not convinced, that it would be a good idea, thou.
>
> I am just giving an discussion topic.
>
> it works for unique_together
> why not to add:
>
> unique = ('name', 'login', 'ssn')
> db_index = ('name', 'login')
> auto_add = ('signup_date', )
> auto_add_now = ('last_mod', )
> null = ('comment', 'first_name')
>
> ... and so on ...
>
> What do you think?
>
>
> --
> Matt Harasymczuk
> http://www.matt.harasymczuk.pl
>
> --
> 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 unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>

Sounds like a bad idea to me.  unique_together doesn't exist on a specific
field precisely because it isn't an option for any specific fields, it's for
a set of fields.  All the other options belond to specific fields.

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

-- 
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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

model fields options

[Mateusz Harasymczuk]

I had an idea.

To move model fields options, such as:
- blank=BOOL
- null=BOOL
- auto_add=BOOL
- auto_add_now=BOOL
- db_index=BOOL

and others boolean options to Meta class of this model.

It would make model fields more readable and human friendly.
However I am not convinced, that it would be a good idea, thou.

I am just giving an discussion topic.

it works for unique_together
why not to add:

unique = ('name', 'login', 'ssn')
db_index = ('name', 'login')
auto_add = ('signup_date', )
auto_add_now = ('last_mod', )
null = ('comment', 'first_name')

... and so on ...

What do you think?


--
Matt Harasymczuk
http://www.matt.harasymczuk.pl

-- 
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 unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.