Re: [SQLObject] rename notNull -> required, SQL check constraints

On Thu, 2003-04-10 at 10:02, Bud P.Bruegger wrote:
> Another thought on the relationship of alternateID and notNull:
> 
> Doesn't the former imply the latter?  If so, maybe the interface can
> be simplified.

Yes, the two should go together.

> Also, considering that SQLObject kind of hides the SQL and attempts a
> pythonic touch and feel, I don't like the term "notNull" since Null
> really comes from SQL world.  NotNone would be more pythonic (but
> ugly), but what about "required"?

No, to me NOT NULL is not the same as required.  "Required" can be
interpreted both as if the column has a default, and if NULL is
allowed.  And then it could get confused with other requirements, like a
requirement like first_name can't be empty ('').  The empty string in
many cases is just as ambiguous as NULL.

I know NULL is special in SQL, but I don't treat it as all that special,
and I know many other people don't either.  notNone would be okay,
though I don't mind the SQL analog that comes through in notNull.  I
*don't* feel NULL is the absence of a value in a general sense -- what
it means is contextual, just like None.

> And a change of topic:
> Just for completeness, it would be nice to also add Col keyword
> argument check, for example check="price > 0",  and a special
> attribute _checks, for example _checks=[check("marriageDate >
> birthDate")], to access Check constraints of SQL.  (See
> http://www.postgresql.org/docs/view.php?version=7.3&idoc=1&file=ddl-constraints.html#AEN1793).  

I'm reluctant to add direct hooks for table creation.  If you want close
control over your schemas it's still better to construct them manually
-- maybe at some point SQLObject will be more complete, but I don't want
to add things simply to force it to be complete.

In this case the check argument is an opaque hook to the schema creation
-- SQLObject can't understand what your asking, it can only pass it on
to the database.  That's something I want to avoid.

  Ian