Re: find with null

to answer on your link:
as you can see there are many issues with NULL values.
Aggregate (summary) functions don't work the way they would if you'd
use default values.

for most people, this is not the desired behavior
and as for many other reasons you should always use default values IF
(!) there is no good reason to do otherwise.

if you have a reason - well, thats fine.
but in your case there is none (your title field).
you could even end up with NULL values + empty string values ('') in
one database. if you want to check on empty fields you would need a
double check (x IS NULL OR x = ''). I dont see any point in that,
independently from any database, framework or platform.

On 4 Okt., 15:56, Jack Timmons <codeac...@codeacula.com> wrote:
> On Mon, Oct 4, 2010 at 8:20 AM, lyba <l...@poczta.fm> wrote:
> > having spent some more time pondering 'NULL is not an appropriate
> > value to work with'
> > I would tend to agree with some objections - two reasons:
>
> > 1. null means field has not been handled (no info whether
> > intentionally or not) - newly entered fields have null values - if you
> > work then record by record how would you know with null that you have
> > already decided to leave it that way.
>
> > 2. Cake form edit:
> > - for integer fields enters 0, unless it is select box and you define
> > default to null field property
> > - for text fields enters empty string
>
> > therefore null sometimes is and sometimes is not an appropriate field
> > to work with
>
> > nonetheless cake's inability to handle properly above condition is a
> > defect with a workaround solution
>
> Although this seems to be drifting toward opinion (since I wanted a
> technical reason NULL shouldn't be used, not one relating to
> people/frameworks not understanding the difference), I will submit
> this:
>
> A field that accepts a serialized string from PHP has wholly different
> meaning if the field is "" compared to if the field is NULL. The first
> implies no data was placed on purpose. The other implies this field
> hasn't had anything done with it. This tells you if the field was
> purposefully left empty or defaulted to NULL. One wouldn't need
> anything outside of SQL to know this.
>
> One cannot simply "test on empty" as others have stated. What happens
> when "" or 0 are valid inputs? For basic situations, you may not need
> to consider NULL, but that doesn't mean it shouldn't be used. It just
> means you don't care to use it. Saying it shouldn't be used in a broad
> manner without any technical evidence why it shouldn't be is a fallacy
> in logic.
>
> Finally, at least in regard to the internet and following my own
> opinion, one should -never- have to shape their database in regard to
> the software that will use it. Because CakePHP fails at handling NULL
> fields as desired by those of the community (it seems) doesn't mean
> that one should not use NULL. As demonstrated above, NULL is perfectly
> fine and is beyond useful. If you need guidance on the uses of it, I
> suggested reading MySQL's guide on NULL fields, specifically "Problems
> with NULL values" listed below.
>
> http://dev.mysql.com/doc/refman/5.1/en/problems-with-null.html
>
> --
> Jack Timmons
> @_Codeacula

Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions.

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