sqlobject-discuss

[SQLObject] Default=None should do nothing.

[Mike W. <li...@mi...>]

Here's a problem I've run across, perhaps others have solved it:

create table test (
id serial,
foo varchar(20),
creation_date timestamp default now()
);

class Test(SQLObject):
  foo=StrCol(length=20, default=None)
  creation_date=DateTimeCol(default=None)

When creating new Test objects, I do not want creation_date to be set to
null; I want the database to look after setting defaults. For the time
being I am passing a function

  creation_date=DateTimeCol(default=date.now)

but that doesn't truly resolve the issue for me as I'd prefer to have
the database (postgres) deal with the time stamps. This makes it easier
to coexist with other apps or sql scripts directly manipulating the DB.

I understand that I can use SQLBuilder to pass a db function on, but
still if possible I'd prefer that somethings be handled in the
background by the database, and accept that I might need to use
obj.sync(), perhaps in conjunction with _lazyUpdates.

Perhaps I've missed something. It won't be the last time.

Mike

--

Meskimen's Law: There's never time to do it right, but there's always
time to do it over.

[SQLObject] Re: Adding DB auto-timestamping to DateTimeCol

[Chris G. <ch...@il...>]

On 30 Jul 2004, Mike Watkins said:

> class Test(SQLObject):
>   foo=StrCol(length=20, default=None)
>   creation_date=DateTimeCol(default=None)
> 
> When creating new Test objects, I do not want creation_date to be set
> to null; I want the database to look after setting defaults. For the
> time being I am passing a function
> 
>   creation_date=DateTimeCol(default=date.now)
> 
> but that doesn't truly resolve the issue for me as I'd prefer to have
> the database (postgres) deal with the time stamps. This makes it
> easier to coexist with other apps or sql scripts directly manipulating
> the DB. 

That's a good point. With a cluster of machines making calls to one
central database, the date.now() could return a different time depending
on which machine the code was being run on. And, as you said, it's
better to let the DB do the timestamping when you're mixing SQLObject
with other non-SQLObject apps that also use the DB. 

I think we should fix this. How about adding a boolean to the
DateTimeCol class' constructor, like this: 

    timestamp = DateTimeCol(autoTimestamp=True)

That could work. Is "autoTimestamp" a keyword people are familiar with?
:) 

Re: [SQLObject] Re: Adding DB auto-timestamping to DateTimeCol

[Luke O. <lu...@me...>]

> I think we should fix this. How about adding a boolean to the
> DateTimeCol class' constructor, like this:
>
>    timestamp = DateTimeCol(autoTimestamp=True)
>
> That could work. Is "autoTimestamp" a keyword people are familiar with?
> :)

Isn't this a more generic idea, saying "not a required field, and don't include
when creating"? Ie, a flag that could apply to any Col type, not just
DateTimeCol? Right now, my understanding is that we can have fields that
aren't required for creating SO objects, but SO requires a default
value/function to use in that case and includes it in the INSERT statement.
Not sure what word to use for the flag, "auto" by itself is the right concept
but pretty generic. "autoInsert"? "databaseDefault"? "defaultFromDatabase"?

- Luke

Re: [SQLObject] Re: Adding DB auto-timestamping to DateTimeCol

[Andrew B. <and...@pu...>]

On Sat, Aug 14, 2004 at 02:51:28PM -0500, Luke Opperman wrote:
[...]
> 
> Isn't this a more generic idea, saying "not a required field, and don't 
> include
> when creating"? Ie, a flag that could apply to any Col type, not just
> DateTimeCol? Right now, my understanding is that we can have fields that
> aren't required for creating SO objects, but SO requires a default
> value/function to use in that case and includes it in the INSERT statement.
> Not sure what word to use for the flag, "auto" by itself is the right 
> concept
> but pretty generic. "autoInsert"? "databaseDefault"? "defaultFromDatabase"?

There's already a "default" flag.  When left with its default value
(NoDefault), probably SQLObject should just omit it from the INSERT
statement, rather than refuse to even try (or perhaps there should be a
default=OmitOk or something).  Currently, there's no way to make use of a
"DEFAULT ..." declaration in a table definition.

-Andrew.

Re: [SQLObject] Re: Adding DB auto-timestamping to DateTimeCol

[Michael W. <li...@mi...>]

On Sun, 2004-08-15 at 01:10 +0100, Andrew Bennetts wrote:
> There's already a "default" flag.  When left with its default value
> (NoDefault), probably SQLObject should just omit it from the INSERT
> statement, rather than refuse to even try (or perhaps there should be
> a default=OmitOk or something).  Currently, there's no way to make use
> of a "DEFAULT ..." declaration in a table definition.

Yup, exactly. And that breaks the "SQLObject should fit in with existing
schema's" goal.

[SQLObject] Re: Re: Adding DB auto-timestamping to DateTimeCol

[Chris G. <ch...@il...>]

On 15 Aug 2004, Michael Watkins said:

> On Sun, 2004-08-15 at 01:10 +0100, Andrew Bennetts wrote:
>> There's already a "default" flag.  When left with its default value
>> (NoDefault), probably SQLObject should just omit it from the INSERT
>> statement, rather than refuse to even try (or perhaps there should be
>> a default=OmitOk or something).  Currently, there's no way to make
>> use of a "DEFAULT ..." declaration in a table definition.
> 
> Yup, exactly. And that breaks the "SQLObject should fit in with
> existing schema's" goal.

Alright. So the solution is to have some way of telling it to use the
database's built-in default value if it exists. 

It should probably be a boolean paramter to Col(), for simplicity.
Something like "defaultFromDB=True"? "useDBDefault=True"? 

I don't like the "omit" bit. Too many negatives can get confusing,
especially with booleans (eg. notNull=False). :)