|
From: Ian B. <ia...@co...> - 2003-04-11 19:25:21
|
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
|
