Re: [Django] #13354: Possible bug, or possible docs error.

[Django]

#13354: Possible bug, or possible docs error.
---+
  Reporter:  orokusaki | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:  invalid   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by russellm):

 I don't think you are being fair to Karen at all. In fact, you could
 easily be accused of doing exactly the same thing that you have accused
 Karen of doing. Karen said:

 > The fact that a particular field's implementation of get_prep_value uses
 its to_python method does not make it wrong, it just means for that
 particular field type that makes sense.

 Which is both correct, and consistent with what I said:

 > That is, the equivalence of get_prep_value and to_python is entirely
 consistent with the desired behavior on those fields.

 Karen's comments say the same thing as I did -- I just gave more specific
 examples. That's not a "straw hat".

 Karen also called into question whether you need a custom field at all.
 Based on the limited detail you provided, Karen couldn't see why a custom
 field is required -- and I can't either. What you seem to be describing is
 a set of basic data validation constraints, which is not the usual use
 case for a custom field that is reimplementing to_python() and
 get_prep_value(). The direction to seek out django-users was aimed --
 correctly -- at encouraging you to seek out the right solution to the
 problem, rather than fixating on a complex way of solving the problem that
 may ultimately work but require a lot more effort. This isn't a "straw
 hat" either.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13354: Possible bug, or possible docs error.

[Django]

#13354: Possible bug, or possible docs error.
---+
  Reporter:  orokusaki | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:  invalid   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by orokusaki):

 Replying to [comment:5 russellm]:

 Thanks for explaining why I was wrong. Sorry for wasting yet more time on
 hasty invalid conclusions. I still hold my position that the desired
 equivalent behavior would be best handled always in two separated methods,
 but to subclass and make a minor edit like that isn't the biggest deal.

 I felt like all kmtracey did was pull out a straw hat.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13354: Possible bug, or possible docs error.

[Django]

#13354: Possible bug, or possible docs error.
---+
  Reporter:  orokusaki | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:  invalid   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * milestone:  1.2 =>

Comment:

 Replying to [comment:3 orokusaki]:
 > My concern is that the '''same method is being called to render the DB
 value out''' to its Python value (which then is output in my model form to
 the user) '''as well as to prep what the user inputs for the DB again'''.
 This is very incorrect and needs to be addressed in some way (either by
 changing the docs, or patching).

 It's not 'very incorrect' at all.

 Firstly, you will note that the get_prep_value/to_python equivalence is
 only true on 5 of Django's builtin fields:CharField, DateField,
 DateTimeField, DecimalField and TimeField. The default implementation of
 both get_prep_value and to_python is "return value".

 Secondly, you will note the following pattern:
  * CharField - whatever the user gives you, insert unicode. Whatever the
 database provides you, return unicode.
  * [Date|Time|DateTime]Field - whatever the user gives you, turn it into a
 date/time/datetime. Whatever the backend gives you (and there is some
 variation), turn it into a date/time/datetime.
  * DecimalField - whatever the user gives you, turn it into a Decimal.
 Whatever the database provides you, turn it into a Decimal.

 That is, the equivalence of get_prep_value and to_python is entirely
 consistent with the desired behavior on those fields.

 As for the original query - there certainly is a way to have a field
 output a modified value without also modifying it on the way in - do
 exactly what the documentation suggests, and define *both* methods.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13354: Possible bug, or possible docs error.

[Django]

#13354: Possible bug, or possible docs error.
---+
  Reporter:  orokusaki | Owner:  nobody
Status:  closed| Milestone:  1.2   
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:  invalid   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by orokusaki):

 One final note. You mentioned:

 >> The fact that a particular field's implementation of get_prep_value
 uses its to_python...

 This really matters because {{ to_python }} is provided in the docs as
 part of the '''public API''' to hook in your own functionality. It even
 gives specific details on how to ensure it's run each time. It's not
 simply a matter of behind-the-scenes implementation.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13354: Possible bug, or possible docs error.

[Django]

#13354: Possible bug, or possible docs error.
---+
  Reporter:  orokusaki | Owner:  nobody
Status:  closed| Milestone:  1.2   
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:  invalid   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by orokusaki):

 * cc: kmtracey (added)

Comment:

 @kmtracey

 I'm not calling the code myself in my application. I understand how to
 write custom model fields (I have about 9 in my current project), and I'm
 not looking for free support. My concern is that the '''same method is
 being called to render the DB value out''' to its Python value (which then
 is output in my model form to the user) '''as well as to prep what the
 user inputs for the DB again'''. This is very incorrect and needs to be
 addressed in some way (either by changing the docs, or patching).

 If you read my entire ticket before answering and closing my ticket next
 time, this miss-communication won't occur.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13354: Possible bug, or possible docs error.

[Django]

#13354: Possible bug, or possible docs error.
---+
  Reporter:  orokusaki | Owner:  nobody
Status:  closed| Milestone:  1.2   
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:  invalid   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by kmtracey):

  * status:  new => closed
  * resolution:  => invalid

Comment:

 Notice you are reading the documentation for Writing Custom Model Fields.
 This doc is attempting to describe what your implementation of these
 methods needs to do, when you are writing your own custom model field.
 These are methods used internally when retrieving data from the DB and
 sending it back: these are not methods that application-level code ought
 to be calling. The fact that a particular field's implementation of
 `get_prep_value` uses its `to_python` method does not make it wrong, it
 just means for that particular field type that makes sense.

 Getting answers to your questions of how to handle password field display
 and display of monetary values would be better done by asking questions on
 #django IRC or the django-users mailing list. Neither of these tasks
 requires writing a custom model field, so I think you are looking at the
 wrong level for answers here.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13354: Possible bug, or possible docs error.

[Django]

#13354: Possible bug, or possible docs error.
---+
  Reporter:  orokusaki | Owner:  nobody
Status:  new   | Milestone:  1.2   
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by orokusaki):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 After reading this myself, I decided it wasn't clear what I was trying to
 do when I encountered this.

 I'm trying to output an empty string so that when I display a password
 field, it is always empty. When the user submits the form, the password
 should not be emptied on the way back to the database. The same goes for
 formatting money so that users can see it in money format, but then when
 it's stored I would want to strip the dollar sign.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.