[sqlalchemy] Re: Column class with NULL=False

2008-07-12 Thread Kless

Well, the programs has backward incompatibility prior version 1.0

On Jul 12, 5:46 pm, Rick Morrison [EMAIL PROTECTED] wrote:
 This would be very ugly for backward compatibility. If you want non-null,
 then just say so in your metadata. Jamming relational design dogma down
 everyone's throat is not a great recipe for library uptake.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---



[sqlalchemy] Re: Column class with NULL=False

2008-07-12 Thread Michael Bayer


On Jul 12, 2008, at 11:42 AM, Kless wrote:


 Michael, why don't change the 'Column' class values to *nullable =
 False, default=''* ?

 After of reading the down articles I think that set NULL to False by
 default will avoid possible errors to many people.

 NULL means something is unknown. [1]

 NULL needs to be used with prudence and with care. Just because the
 database supports the use of NULL doesn’t mean that you should design
 for NULL. Rather, a good design will prevent the overuse of  NULL.
 Although I said that a good implementation will prevent uncertainty of
 NULL, it is important to note that NULL can be ambiguous and cause
 uncertainty if used improperly. [2]

 It looks enought logical the Django's position respect to NULL [3]:

 Default is False.

 Note that empty string values will always get stored as empty strings,
 not as NULL. Only use null=True for non-string fields such as
 integers, booleans and dates.

 Avoid using null on string-based fields unless you have an excellent
 reason. If a string-based field has null=True, that means it has two
 possible values for “no data”: NULL, and the empty string. In most
 cases, it’s redundant to have two possible



Unlike Django, SQLAlchemy is only a library, not a framework.
SQLAlchemy is non-opinionated and doesn't believe in nannying its  
users, who are assumed to already know what they want SQL-wise when  
using our toolkit.  In particular the default value of nullable  
mirrors that of SQL DDL language itself which is the driving force  
behind the choices made in the schema module.   Personally I use NULLs  
by default all the time when prototyping (which is the primary use  
case for SQLA's DDL generation feature) since I want to lay out the  
tables in a test database fully, but would like an only partially- 
complete application (which doesn't yet write to every column) to  
still run successfully.A production application OTOH would have a  
schema that's been more carefully tailored, either through hand-coded  
DDL or from DDL that's been dumped from a development database, after  
the schema has been carefully tuned to completion.




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---