|
From: Brad B. <br...@bb...> - 2003-04-30 13:57:04
|
I have a class:
class MerchantAccount(SQLObject):
_columns = [
StringCol('merchantID', length = 15, alternateID = True, notNull = True),
StringCol('companyName', length = 50, notNull = True),
StringCol('address1', length = 255, notNull = False),
StringCol('address2', length = 255, notNull = False),
IntCol('telephone', notNull = False),
IntCol('fax', notNull = False),
StringCol('url', length = 100, notNull = False),
StringCol('lang', length = 6, notNull = False)
]
MultipleJoin('MerchantProxyAccount')
and then in a nearby piece of code, an insert:
from merchant import MerchantAccount, MerchantProxyAccount, PurchaseTransaction
ma = MerchantAccount.new(merchantID = "foo", companyName = "bar")
When run, this raises an error:
bradb@mothra:~/1ave/merchant/scripts$ python insert_test_data.py
Traceback (most recent call last):
File "insert_test_data.py", line 5, in ?
ma = MerchantAccount.new(merchantID = "desjardins", companyName = "Premiere Avenue")
File "/usr/lib/python2.2/site-packages/SQLObject/SQLObject.py", line 682, in new
raise TypeError, "%s did not get expected keyword argument %s" % (cls.__name__, repr(column.name))
TypeError: MerchantAccount did not get expected keyword argument 'address1'
Can we change the behaviour of this to "feel" more like an SQL insert,
so that if a column's allowed to be null, I don't have to specify it
in the new()?
--
Brad Bollenbach
BBnet.ca
|
|
From: Nick <ni...@dd...> - 2003-04-30 15:30:40
Attachments:
diff
|
On Wed, 2003-04-30 at 08:55, Brad Bollenbach wrote: > Can we change the behaviour of this to "feel" more like an SQL insert, > so that if a column's allowed to be null, I don't have to specify it > in the new()? This patch should do what you want. Note that I've changed notNull to default to True instead of False, because it seems to make more sense to do so. If you *don't' specify a keyword argument to new, I would think you would *want* to see an error there instead if you didn't specifically tell it to not expect one. Nick |
|
From: Brad B. <br...@bb...> - 2003-05-01 18:05:20
|
On 05/01/03 12:20, Luke Opperman wrote: > > > Yes, but "NULL" is just computerese for "no value". :) > > Maybe in your world. :) Ok, I guess I'll concede for now. Was this > whole discussion just about whether notNull=False should imply > default=None? I'm still not convinced that my statement: "a field > that CAN have a NULL (notNull=False), but that you still want > explicitly declared (no default)" is useless or gibberish, but > that's probably such a rare case that .... screw 'em. Optimizing for the common case. :) Not forcing the programmer to specify default = None can save a heck of a lot of typing, and happily keep SQLObject completely unsurprising. -- Brad Bollenbach BBnet.ca |
|
From: Nick <ni...@dd...> - 2003-04-30 15:41:38
|
sorry, I send the wrong diff from an earlier try... this is the correct
one. I'll also smack it in the message body so the list can see it.
Nick
Index: SQLObject/Col.py
===================================================================
RCS file: /cvsroot/sqlobject/SQLObject/SQLObject/Col.py,v
retrieving revision 1.17
diff -u -u -r1.17 Col.py
--- SQLObject/Col.py 29 Apr 2003 09:37:06 -0000 1.17
+++ SQLObject/Col.py 30 Apr 2003 15:38:38 -0000
@@ -20,7 +20,7 @@
def __init__(self, name=None, dbName=None, default=NoDefault,
foreignKey=None,
alternateID=False, alternateMethodName=None,
- constraints=None, notNull=False,
+ constraints=None, notNull=True,
unique=NoDefault):
# This isn't strictly true, since we *could* use backquotes
# around column names, but why would anyone *want* to
Index: SQLObject/SQLObject.py
===================================================================
RCS file: /cvsroot/sqlobject/SQLObject/SQLObject/SQLObject.py,v
retrieving revision 1.30
diff -u -u -r1.30 SQLObject.py
--- SQLObject/SQLObject.py 29 Apr 2003 09:47:48 -0000 1.30
+++ SQLObject/SQLObject.py 30 Apr 2003 15:38:39 -0000
@@ -674,7 +674,7 @@
# Then we check if the column wasn't passed in, and
# if not we try to get the default.
- if not kw.has_key(column.name):
+ if not kw.has_key(column.name) and column.notNull:
default = column.default
# If we don't get it, it's an error:
------- end of patch -------
On Wed, 2003-04-30 at 08:55, Brad Bollenbach wrote:
> I have a class:
>
> class MerchantAccount(SQLObject):
> _columns = [
> StringCol('merchantID', length = 15, alternateID = True, notNull = True),
> StringCol('companyName', length = 50, notNull = True),
> StringCol('address1', length = 255, notNull = False),
> StringCol('address2', length = 255, notNull = False),
> IntCol('telephone', notNull = False),
> IntCol('fax', notNull = False),
> StringCol('url', length = 100, notNull = False),
> StringCol('lang', length = 6, notNull = False)
> ]
> MultipleJoin('MerchantProxyAccount')
>
> and then in a nearby piece of code, an insert:
>
> from merchant import MerchantAccount, MerchantProxyAccount, PurchaseTransaction
>
> ma = MerchantAccount.new(merchantID = "foo", companyName = "bar")
>
> When run, this raises an error:
>
> bradb@mothra:~/1ave/merchant/scripts$ python insert_test_data.py
> Traceback (most recent call last):
> File "insert_test_data.py", line 5, in ?
> ma = MerchantAccount.new(merchantID = "desjardins", companyName = "Premiere Avenue")
> File "/usr/lib/python2.2/site-packages/SQLObject/SQLObject.py", line 682, in new
> raise TypeError, "%s did not get expected keyword argument %s" % (cls.__name__, repr(column.name))
> TypeError: MerchantAccount did not get expected keyword argument 'address1'
>
> Can we change the behaviour of this to "feel" more like an SQL insert,
> so that if a column's allowed to be null, I don't have to specify it
> in the new()?
|
|
From: Ian B. <ia...@co...> - 2003-04-30 20:53:20
|
On Wed, 2003-04-30 at 10:29, Nick wrote: > On Wed, 2003-04-30 at 08:55, Brad Bollenbach wrote: > > Can we change the behaviour of this to "feel" more like an SQL insert, > > so that if a column's allowed to be null, I don't have to specify it > > in the new()? > > This patch should do what you want. Note that I've changed notNull to > default to True instead of False, because it seems to make more sense to > do so. If you *don't' specify a keyword argument to new, I would think > you would *want* to see an error there instead if you didn't > specifically tell it to not expect one. I don't know... just because you don't give a default, you can still use None for a value (assuming the column allows NULL). It was my intention to make the default explicit, even if it isn't explicit in SQL, so default=None does what Brad wants. I can see why it would be inconvenient, but only slightly, and I think that's countered by it being a useful discipline (and more closely matching Python, which doesn't use implicit defaults). Ian |
|
From: Nick <ni...@dd...> - 2003-04-30 21:19:14
|
On Wed, 2003-04-30 at 15:54, Ian Bicking wrote: > It was my intention to make the default explicit, even if it isn't > explicit in SQL, so default=None does what Brad wants. I can see why it > would be inconvenient, but only slightly, and I think that's countered > by it being a useful discipline (and more closely matching Python, which > doesn't use implicit defaults). But on the other had, I think he has a point about the notNull field. And we are getting back to Pythonic vs. SQL naming conventions. IMHO, being of little weight since I've only recently stuck my nose in, I think your class definitions should look like SQL, while class *usage* should look like Python. Because, chances are the designer knows much about SQL and will be easy to generate those classes from schema knowledge, while your end API user may (probably) doesn't know (or need to know) about the schema structure or even SQL for most things. Plus, it'll make the whole thing easier to debug from a mapping point of view. Maybe the constructor should map a default of None automatically if notNull is False and there is no default specified. In that case, though I would think you would still want notNull to default to True rather than False. In other words, I think it's just wierd to stipulate that if you have to say default=None if you've already specified notNull=False. Nick |
|
From: Brad B. <br...@bb...> - 2003-05-01 12:40:34
|
On 04/30/03 15:54, Ian Bicking wrote:
> On Wed, 2003-04-30 at 10:29, Nick wrote:
> > On Wed, 2003-04-30 at 08:55, Brad Bollenbach wrote:
> > > Can we change the behaviour of this to "feel" more like an SQL insert,
> > > so that if a column's allowed to be null, I don't have to specify it
> > > in the new()?
> >
> > This patch should do what you want. Note that I've changed notNull to
> > default to True instead of False, because it seems to make more sense to
> > do so. If you *don't' specify a keyword argument to new, I would think
> > you would *want* to see an error there instead if you didn't
> > specifically tell it to not expect one.
>
> I don't know... just because you don't give a default, you can still use
> None for a value (assuming the column allows NULL).
>
> It was my intention to make the default explicit, even if it isn't
> explicit in SQL, so default=None does what Brad wants. I can see why it
> would be inconvenient, but only slightly, and I think that's countered
> by it being a useful discipline (and more closely matching Python, which
> doesn't use implicit defaults).
To me:
default=None
reads essentially "if no value is specified, this column has no
value", which is redundant. I think it would be reasonable for
SQLObject to internalize the default=None when no default value is
specified, in much the same way that I'm always writing functions
like:
def foo(bar, baz = None):
x = bar
if baz is not None:
....
What do you guys think?
--
Brad Bollenbach
BBnet.ca
|
|
From: Luke O. <lu...@me...> - 2003-05-01 14:43:56
|
> To me: > > default=None > > reads essentially "if no value is specified, this column has no > value", which is redundant. I think it would be reasonable for > SQLObject to internalize the default=None To me, "None is NULL" for SQLObject, so it reads "if no value is specified, this column is NULL". notNull=False is still independent of this: I take default to mean "you don't need to be explicit in setting this field, we have a default". You could easily have a field that CAN have a NULL (notNull=False), but that you still want people to explicitly declare. In my mind. - Luke |
|
From: Brad B. <br...@bb...> - 2003-05-01 15:00:21
|
On 05/01/03 09:29, Luke Opperman wrote: > > > To me: > > > > default=None > > > > reads essentially "if no value is specified, this column has no > > value", which is redundant. I think it would be reasonable for > > SQLObject to internalize the default=None > > To me, "None is NULL" for SQLObject, so it reads "if no value is > specified, this column is NULL". notNull=False is still independent Yes, but "NULL" is just computerese for "no value". :) > of this: I take default to mean "you don't need to be explicit in > setting this field, we have a default". You could easily have a field > that CAN have a NULL (notNull=False), but that you still want people > to explicitly declare. In my mind. And "allowed to be null" is computerese for "allowed to have no value". "Allowed to have no value, except you have to specify some default value" doesn't make sense, in my mind. What's the point of allowing something to have no value, but forcing you to specify a value (even if just as a default)? -- Brad Bollenbach BBnet.ca |
|
From: Luke O. <lu...@me...> - 2003-05-01 17:34:25
|
> Yes, but "NULL" is just computerese for "no value". :) Maybe in your world. :) Ok, I guess I'll concede for now. Was this whole discussion just about whether notNull=False should imply default=None? I'm still not convinced that my statement: "a field that CAN have a NULL (notNull=False), but that you still want explicitly declared (no default)" is useless or gibberish, but that's probably such a rare case that .... screw 'em. It only comes up because "default" is overloaded to both provide a default value and to control explict definition in the object interface, but I can't think of a non-rediculous way to separate these. - Luke |
|
From: Ian B. <ia...@co...> - 2003-05-05 18:12:52
|
On Thu, 2003-05-01 at 12:20, Luke Opperman wrote: > > Yes, but "NULL" is just computerese for "no value". :) > > Maybe in your world. :) Ok, I guess I'll concede for now. Was this > whole discussion just about whether notNull=False should imply > default=None? I'm still not convinced that my statement: "a field > that CAN have a NULL (notNull=False), but that you still want > explicitly declared (no default)" is useless or gibberish, but > that's probably such a rare case that .... screw 'em. I don't agree with this. To me NULL (and None) has a very specific meaning, though that meaning is usually context-specific (not specified, not known, not applicable, etc). It isn't the same as "default". Python does not use None as a default (except the get method on dictionaries). Instead None must be specified explicitly, in argument lists or elsewhere. I think this is the appropriate behavior for SQLObject to take on as well. Writing "default=None" just doesn't seem that difficult to me. Now, I'm not entirely convinced on this, but if we have a "default" argument to Col anyway, I'd prefer to be explicit about it. Ian |
