Re: MySQL Defaults and EOF (was Cheap (or open source) RDB for Windows compatible with WO ...)

Kieran Kelleher <[email protected]> Wed, 25 Feb 2004 13:06:13 -0500
Newsgroups gmane.comp.web.webobjects.eof,gmane.comp.web.webobjects.devel
Message-ID <[email protected]>
Here is some more info on that in case anyone is interested.

Here is excerpt from http://www.mysql.com/doc/en/CREATE_TABLE.html

------------------------------------------------------------------------ 
------------------------------------------------------------------------ 
-
	▪ 	 A DEFAULT value must be a constant; it cannot be a function or an  
expression.  If no DEFAULT value is specified for a column, MySQL  
automatically assigns one, as follows.  If the column may take NULL as  
a value, the default value is NULL.  If the column is declared as NOT  
NULL, the default value depends on the column type:
	▪ 	 For numeric types other than those declared with the  
AUTO_INCREMENT attribute, the default is 0. For an AUTO_INCREMENT  
column, the default value is the next value in the sequence.
	▪ 	 For date and time types other than TIMESTAMP, the default is the  
appropriate zero value for the type. For the first TIMESTAMP column in  
a table, the default value is the current date and time. See section  
11.2 Date and Time Types.
	▪ 	 For string types other than ENUM, the default value is the empty  
string. For ENUM, the default is the first enumeration value.
  Default values must be constants. This means, for example, that you  
cannot set the default for a date column to be the value of a function  
such as NOW() or CURRENT_DATE.
------------------------------------------------------------------------ 
------------------------------------------------------------------------ 
-

Note where it says "If the column may take NULL as a value, the default  
value is NULL.  If the column is declared as NOT NULL, the default  
value depends on the column type", thus since we know that EOF defaults  
attributes to NULL, then it is OK not to initialize attributes that  
your EO does not initialize ONLY if you have set them to allow NULL in  
the database, which means DEFAULT NULL, not some other default.  
However, if you have a NOT NULL EOModel item, then EOF will not let you  
save it anyway without assigning a value, so the DB may be set to NOT  
NULL aswell just as long as you are happy with the automatic default if  
you do not specify it.

All of this shows the importance of minimizing your use of database  
"features" because the db feature may clash with your EOModel attribute  
specification!
____________________________________
OS X 10.3.2 /  WO 5.2.2 / MySQL 4.0.16
Blog: http://webobjects.webhop.org/


On Feb 25, 2004, at 10:45 AM, Kieran Kelleher wrote:

> Have not been bitten by this.... but I did a little experimenting to  
> decide whether I should use database defaults or initialize my  
> defaults in my EO's when they are first created. The answer is simply  
> to use NULL as default since that is what EOF does, or if you are  
> going to have zero as a default for example in the DB, then make sure  
> the EO initializes the same attribute as zero when it is created.  
> Otherwise the EOF "snapshot" will not match what was written tom the  
> database and you will get an exception when you save.
>
> More on this here:
> http://homepage.mac.com/kelleherk/iblog/C729512539/index.html
>
> On Feb 25, 2004, at 4:11 AM, Dirk Olmes wrote:
>
>>> So far, I like MySQL, it's free, very fast, and its "shortcomings"  
>>> may
>>> indeed be features that you do not need when the sophisticated EOF in
>>> WO is controlling it with standard ANSI SQL 92.
>>
>> Well, I can't second that opinion. Ever been bitten by the famous
>> default-value-for-not-null-columns "feature"?  I didn't invest any  
>> more
>> energy in finding out why EOF leaves out columns on insert but moved  
>> all
>> of my databases to PostgreSQL. Happy ever since :-)
>>
>> In terms of support, I like the MySQL Windows tools better but  
>> postgres
>> tools seem to catch up. One thing that really sucks about PostgreSQL  
>> ist
>> the need for VACUUMs, even if you can do it in parallel to normal
>> operations now.
>>
>> -dirk
>>
>>
>> _______________________________________________
>> EOF mailing list
>> [email protected]
>> http://www.omnigroup.com/mailman/listinfo/eof
>>
>
>

_______________________________________________
EOF mailing list
[email protected]
http://www.omnigroup.com/mailman/listinfo/eof