sqlobject-discuss — All things SQLObject-related

[SQLObject] Validating data

[Hendrik M. <hen...@gm...>]

Hi everyone,

what would be the "cleanest" way of doing data validation for
new/updated SQLObjects? Basically, I want to apply some basic
constraints on my data fields, things like checking for minimum string
lengths, regular expression matching, and so on... and I can't (or
don't want to) do it inside my RDBMS. (Which was suggested in another
posting to this list, I believe.)

Right now, I'm seeing three possibilities, none of which I currently
have that nice and warm "that's the one!" feeling about:

- overriding _init() -- but that won't do validation when updating single fields
- overriding _set_*, but will that work when I create a new SQLObject
through .__init__()?
- setting _lazyUpdate to True and adding validation code to sync() or
syncUpdate()

Also, I just noticed SQLObject includes FormEncode, and Cols can have
a validator attribute... is that where I could apply my own
validators? (Not sure if this is a new feature since 0.6?)

Thanks!

- Hendrik

Re: [SQLObject] Defer creating/updating objects in the database

[Oleg B. <ph...@ma...>]

On Mon, Dec 20, 2004 at 11:01:49AM +1300, Peter Butler wrote:
>                     initStrings.append('%s = self.%s' % (col.name,
> col.name))
>                     allAttrs.remove(col.name)
>                     removeAttrs.append(col.name)
>                 elif col.default is not None and col.default !=
> sqlobject.sqlbuilder.NoDefault:
>                     initStrings.append("%s = %s" % (col.name,
> `col.default`))
>                 else:
>                     initStrings.append('%s = None' % (col.name))
>             initString = '%s(%s)' % (self.clazz.__name__,
> string.join(initStrings, ','))
>             self.object = eval(initString)

   Wow! That's a long and a very wrong way of doing things. This is
Python! Do not evaluate strings - just manipulate objects.

   args = ["arg1", 2, 3.0]
   keywords = {"name1": "valu1", "name2": "value2"}
   self.object = self.clazz(*args, **kywords)

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Defer creating/updating objects in the database

[Peter B. <pet...@14...>]

Thanks for all the advice on this, I really appreciate it.  I've managed
to get this working by using the code below.  You use it like this:

class SomeDomainObject(SQLObject):
    ...etc

# This will create a new object in the database
form = FormValues(clazz = SomeDomainObject)
form.attr1 = 'value1'
form.attr2 = 'value2'
form.save() #Insert deferred to here

# This will update an existing object
obj = SomeDomainObject.select(...)
form = FormValues(object = obj)
form.attr1 = 'newvalue'
form.attr2 = 'newValue2'
form.save() #Update deferred to here

This code works but I'm not very keen on it because it seems like a hack
to, in particular using "eval" to call the object constructor does not
feel good.  Any advice or comments on how to improve this are welcome.

Cheers

Peter

class FormValues:
    def __init__(self, clazz = None, object = None):
        self.clazz = clazz
        self.object = object
        
    def __getattr__(self, attr):
        # If we just want the object (as in 'self.object')
        if attr == 'object' and self.__dict__.has_key('object'):
            return self.__dict__['object']
        # Otherwise, if we have an object, pass the call to it
        elif self.__dict__.has_key('object') and self.__dict__['object']
is not None:
            return getattr(self.__dict__['object'], attr)
        # Otherwise return the attr we have (or None if not found)
        else:
            if self.__dict__.has_key(attr):
                return self.__dict__[attr]
            else:
                return None

    def __setattr__(self, attr, val):
        # Store the attribute to set it on the object later
        self.__dict__[attr] = val

    def save(self):
        # If we haven't been created with an object, create one
        if self.object is None:
            initStrings = []
            removeAttrs = []
            allAttrs = self.__dict__.keys()
            for col in self.clazz._SO_columns:
                if self.__dict__.has_key(col.name):
                    initStrings.append('%s = self.%s' % (col.name,
col.name))
                    allAttrs.remove(col.name)
                    removeAttrs.append(col.name)
                elif col.default is not None and col.default !=
sqlobject.sqlbuilder.NoDefault:
                    initStrings.append("%s = %s" % (col.name,
`col.default`))
                else:
                    initStrings.append('%s = None' % (col.name))
            initString = '%s(%s)' % (self.clazz.__name__,
string.join(initStrings, ','))
            self.object = eval(initString)
            for attr in removeAttrs:
                del self.__dict__[attr]
            # Set the attributes that are not columns
            for key in allAttrs:
                if key != 'object' and key != 'clazz':
                    setattr(self.object, key, self.__dict__[key])
                    del self.__dict__[key]
        else:
            # Otherwise set the values on the object we have
            for key in self.__dict__.keys():
                if key != 'object' and key != 'clazz':
                    setattr(self.object, key, self.__dict__[key])
                    del self.__dict__[key]


> On Thu, 2004-12-09 at 05:51, Ian Bicking wrote:
> > Peter Butler wrote:
> > > I'm just getting to grips with SQLObject so please pardon me if this
> > > is a question that has been asked before.
> > > 
> > > Is it possible to defer the insert/update so that the object can be
> > > validated before the changes are written to the database?
> > > 
> > > I would like to be able to do the following:
> > > 
> > > object = MyObject() 
> >  > object.field1 = someValue
> >  > object.field2 = someValue
> >  > object.validate() object.save()
> > > 
> > > With similar logic for objects that already exist in the database.
> > > 
> > > From looking through the tutorial and source the philosophy seems
> > > to be to write all object changes to the database as they occur.
> > > This makes sense to me as it simplifies everything.
> > 
> > You can also set several keys at once using .set(); you might require 
> > that the object be valid for each call to .set().  You can also delay 
> > saves to the database with _lazyUpdate = True, then you can override the 
> > .syncUpdate() method to do validation.  Hmm... apparently I haven't 
> > included lazyUpdate in the docs, but it is noted in the News.

[SQLObject] Problems with RelatedJoin in 0.6

[Sam N. <sa...@se...>]

Hello,

I am new to sqlobject, and i'm finding it to be a truly wonderful layer 
and model. I have had some problems with RelatedJoin attributes and I 
have seen some talk of that recently on the list. The suggestion to 
explicitly define joinColumn, otherColumn, and joinMethodName solved a 
few different problems that I was having.

Unsolved Problems - I have pasted my 'Group' class below. If I do a 
dir(Group), I see attributes for 'admins' 'users' and more. I also see 
the methods 'addUser' and 'removeUser', *but* there are no corresponding 
'addAdmin' and 'removeAdmin' methods!

I have gathered from the list that the current revision in subversion 
solves some of these problems but may not solve all of them. I am not 
familiar with the state of development, so I want to ask, should I 
update to the newest revision? Is it more stable and less buggy than v.6?

Can anyone help with info about my problem? If the consensus is to 
update to a newer sqlobject, then I will do so and report back.

Thanks for any help!
- Sam Nilsson


from sqlobject import *
from Store import conn

class Group(SQLObject):

         _table = "group_table"
         _connection = conn

         name = StringCol()
         description = StringCol()

         users = RelatedJoin("User", 
intermediateTable='group_table_user', joinColumn='group_table_id', 
otherColumn='user_id', joinMethodName='users')
         admins = RelatedJoin("User", 
intermediateTable='group_table_admin', joinColumn='group_table_id', 
otherColumn='user_id', joinMethodName='admins')
         categories = MultipleJoin("Category", joinColumn='group_id', 
joinMethodName='categories')

Re: [SQLObject] Inheritance

[Oleg B. <ph...@ph...>]

On Thu, Dec 16, 2004 at 05:43:54PM +0300, Oleg Broytmann wrote:
> On Thu, Dec 16, 2004 at 01:16:25PM +0200, Ksenia Marasanova wrote:
> > Employee.select(orderBy='first_name')
> > 
> > produces:
> > 
> >  SELECT employee.id, employee.child_name FROM employee WHERE  1 = 1
> > ORDER BY person.first_name
> > 
> > then Postgres reacts to that like  'NOTICE: adding missing FROM-clause
> > entry for table "person"'
> > 
> > which results in double number of records in the resultset because the
> > tables are not joined properly.

   Please try the attached patch and run
Employee.select(orderBy=Person.q.firstName)
   Does it help?

   Please note that in case you use strings in the query on in the
orderBy (orderBy="first_name") it would not work. As was said by Daniel
Savard:

        #DSM: because if the user uses clauseTables
        #DSM: (and normal string SELECT), he must know what he wants
        #DSM: and will do himself the relationship between classes.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Inheritance

[Oleg B. <ph...@ma...>]

On Thu, Dec 16, 2004 at 06:16:00PM +0200, Ksenia Marasanova wrote:
> This is also the answer to your mail with the test- the test works
> great! But the existing application still has the problem.. weird. .

   Ouch!

> I also noticed that in the "wrong" sql the table names are switched:
> ".... from person, employee... " instead of "... from employee,
> person... " (like in your test).

   The reason for this is that tables are collected in a dictionary, and
dictionaries keys are unsorted. There is no difference for an SQL server.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Inheritance

[Ksenia M. <kse...@gm...>]

It helps, SQLObject now adds extra table name to the query, great.
But, unfortunately, I still have this missing linking statement(x.id =
y.id).
This is also the answer to your mail with the test- the test works
great! But the existing application still has the problem.. weird. .
I also noticed that in the "wrong" sql the table names are switched:
".... from person, employee... " instead of "... from employee,
person... " (like in your test).


Thanks again
--
Ksenia

Re: [SQLObject] Inheritance

[Oleg B. <ph...@ph...>]

On Thu, Dec 16, 2004 at 01:16:25PM +0200, Ksenia Marasanova wrote:
> Employee.select(orderBy='first_name')
> 
> produces:
> 
>  SELECT employee.id, employee.child_name FROM employee WHERE  1 = 1
> ORDER BY person.first_name
> 
> then Postgres reacts to that like  'NOTICE: adding missing FROM-clause
> entry for table "person"'
> 
> which results in double number of records in the resultset because the
> tables are not joined properly.

   The problem is that you haven't gave a query clause, and SQLObject
cannot decide which tables to use. I am not sure if it is a bug. Try
this (with identity clause added to use Person in the query):

   Employee.select(Person.q.lastName==Person.q.lastName, orderBy=Person.q.firstName)

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Inheritance

[Oleg B. <ph...@ph...>]

On Thu, Dec 16, 2004 at 01:54:39PM +0200, Ksenia Marasanova wrote:
> I must be doing something wrong here, because the documentation
> example doesn't work for me eather. The problem is that the clause
> "AND person.id = employee.id" is never added

   Look at the attached test and its log. All SELECTs have neccessary
AND (employee.id = person.id).
   Can you reproduce it?

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Inheritance

[Oleg B. <ph...@ma...>]

On Thu, Dec 16, 2004 at 01:54:39PM +0200, Ksenia Marasanova wrote:
> I must be doing something wrong here

   Not neccessary. I don't remember if it worked in SQLObject 0.5. And
even if it worked the patch can be mangled when we adapted it to 0.6.
I'll look into it.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Inheritance

[Ksenia M. <kse...@gm...>]

I must be doing something wrong here, because the documentation
example doesn't work for me eather. The problem is that the clause
"AND person.id = employee.id" is never added, even when I added search
queries for both tables... Here are my class definitions (slightly
different names from the doc, but with the same structure):

class Person(SQLObject):
    _inheritable = 1
    name = StringCol(length=300, notNone=True)

class Author(Person):
    texts = MultipleJoin('TextAuthor', addRemoveName='Text')

And this simple code:
Author.select(Person.q.name == 'Ksenia')

produces this:
SELECT author.id, author.child_name FROM person, author WHERE 
(person.name = 'Ksenia')


Any help would be greatly appreciated :(

--
Ksenia.

Re: [SQLObject] Inheritance

[Ksenia M. <kse...@gm...>]

Hi,

I don't understand how to use an orderBy parameter with this version.
Or maybe it's a bug? Given the same example, I can't select employees
and order them by first_name. The statement like this:

Employee.select(orderBy='first_name')

produces:

 SELECT employee.id, employee.child_name FROM employee WHERE  1 = 1
ORDER BY person.first_name

then Postgres reacts to that like  'NOTICE: adding missing FROM-clause
entry for table "person"'

which results in double number of records in the resultset because the
tables are not joined properly.

Thanks
--
Ksenia.

Re: [SQLObject] Inheritance

[Oleg B. <ph...@ph...>]

On Tue, Dec 14, 2004 at 09:03:15PM +0200, Ksenia Marasanova wrote:
> I think there is a typo in documentation, in this query:
> 
>     SELECT employee.id, employee.first_name, employee.last_name
>     FROM person, employee WHERE person.first_name = 'Jane'
>     AND employee.position = 'Chief' AND person.id = employee.id
> 
> It should be "person.first_name, person.last_name"

   Fixed in the revision 484. Thank you!

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Inheritance

[Ksenia M. <kse...@gm...>]

>    I've fixed a minor problem with reST in docs/Inheritance.txt. Now I
> am satisfied with the code, the doc, and the test.
>  I am open for discussion.

I think there is a typo in documentation, in this query:

    SELECT employee.id, employee.first_name, employee.last_name
    FROM person, employee WHERE person.first_name = 'Jane'
    AND employee.position = 'Chief' AND person.id = employee.id

It should be "person.first_name, person.last_name"

--
Ksenia

Re: [SQLObject] Re: Bug on SQLBuilder when using strings in the query

[Carlos R. <car...@gm...>]

On Mon, 13 Dec 2004 19:47:09 -0600, Ian Bicking <ia...@co...> wrote:
> SQLObject can't generate SQL without knowing what database it is
> generating SQL for -- in this case, particularly strings.  So you could do:

I'm curious now. This is an example quoted in the SQLBuilder doc:

>>> person.first_name == 'John'
person.first_name = 'John'

In this case, how does it know how to quote the string? (or, in other
words, does this example still work?)

> print Catalog.sqlrepr(Catalog.q.item == '001')
> 
> This calls sqlrepr(Catalog.q.item == '001', Catalog._connection.dbname)
> or something like that.

If the expression on the left side is attached to a db, I think that
it could use this information to format the term on the right side.
For example:

    def __eq__(self, other):
        if other is None:
            return ISNULL(self)
        else:
            return SQLOp("=", self, other)

On the call to SQLOp("=", self, other), a wrapper could be provided
for the "other" term that would fill the db information. Something
like this:

    def __eq__(self, other):
        if other is None:
            return ISNULL(self)
        else:
            return SQLOp("=", self, default_db_wrapper(other, self.db))

Anyway, it's now to late to even start looking at it today. I've
solved my problem partially by writing the queries manually, but I
would like to be able to use SQLBuilder too keep the code cleaner &
more db independent.

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

Re: [SQLObject] Re: Bug on SQLBuilder when using strings in the query

[Ian B. <ia...@co...>]

Carlos Ribeiro wrote:
> On Mon, 13 Dec 2004 22:59:52 -0200, Carlos Ribeiro <car...@gm...> wrote:
> 
>>I'm trying to trace it down, but that's
>>the first time I'm trying to understand SQLBuilder internals, so I
>>thought that it would be good to report it.
> 
> 
> I think I'm beginning to understand how do SQLBuilder works, but
> still, I have no idea on how to solve this problem. The SQLExpression
> class has this code:
> 
>     def __str__(self):
>         return self.__sqlrepr__(None)
> 
> That's the code that is called, and it passes None as the db, in this
> case. But the StringLikeConverter (that is the converter that it finds
> in the registry for a constant string) expects a valid db name:
> 
> def StringLikeConverter(value, db):
>     if db in ('mysql', 'postgres'):
>         for orig, repl in sqlStringReplace:
>             value = value.replace(orig, repl)
>     elif db in ('sqlite', 'firebird', 'sybase', 'maxdb'):
>         value = value.replace("'", "''")
>     else:
>         assert 0, "Database %s unknown" % db
>     return "'%s'" % value
> 
> And that's where the assertion happens. What can I do in this case?
> I'm really lost and looking for ideas :-) I could possibly initialize
> the SQLExpression object with a valid db name (borrowed from the best
> possible candidate it finds while building the expression), but I'm
> not sure about the side effects.

SQLObject can't generate SQL without knowing what database it is 
generating SQL for -- in this case, particularly strings.  So you could do:

print Catalog.sqlrepr(Catalog.q.item == '001')

This calls sqlrepr(Catalog.q.item == '001', Catalog._connection.dbname) 
or something like that.

-- 
Ian Bicking  /  ia...@co...  / http://blog.ianbicking.org

[SQLObject] Re: Bug on SQLBuilder when using strings in the query

[Carlos R. <car...@gm...>]

On Mon, 13 Dec 2004 22:59:52 -0200, Carlos Ribeiro <car...@gm...> wrote:
> I'm trying to trace it down, but that's
> the first time I'm trying to understand SQLBuilder internals, so I
> thought that it would be good to report it.

I think I'm beginning to understand how do SQLBuilder works, but
still, I have no idea on how to solve this problem. The SQLExpression
class has this code:

    def __str__(self):
        return self.__sqlrepr__(None)

That's the code that is called, and it passes None as the db, in this
case. But the StringLikeConverter (that is the converter that it finds
in the registry for a constant string) expects a valid db name:

def StringLikeConverter(value, db):
    if db in ('mysql', 'postgres'):
        for orig, repl in sqlStringReplace:
            value = value.replace(orig, repl)
    elif db in ('sqlite', 'firebird', 'sybase', 'maxdb'):
        value = value.replace("'", "''")
    else:
        assert 0, "Database %s unknown" % db
    return "'%s'" % value

And that's where the assertion happens. What can I do in this case?
I'm really lost and looking for ideas :-) I could possibly initialize
the SQLExpression object with a valid db name (borrowed from the best
possible candidate it finds while building the expression), but I'm
not sure about the side effects.

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

[SQLObject] Bug on SQLBuilder when using strings in the query

[Carlos R. <car...@gm...>]

Hello all,

I'm trying to use a fairly complex query with SQLObject, and was
having a problem with a "AssertionError: Database None unknown" error
message. I've traced it down to this:

class Catalog(SQLObject):
   item_code = StrCol(length=15, notNone=True, alternateID=True)
   item_descr = StrCol(length=40, default='')

print Catalog.q.item_code == 1   # works!
print Catalog.q.item_code == '001'  # does not work!

cribeiro@fiona:~/work/c-l-py $ python test-select-sql-object.py
(catalog.item_code = 1)
Traceback (most recent call last):
 File "test-select-sql-object.py", line 15, in ?
   print Catalog.q.item_code == '001'
 File "/usr/lib/python2.3/site-packages/sqlobject/sqlbuilder.py",
line 157, in __str__
   return self.__sqlrepr__(None)
 File "/usr/lib/python2.3/site-packages/sqlobject/sqlbuilder.py",
line 222, in __sqlrepr__
   return "(%s %s %s)" % (sqlrepr(self.expr1, db), self.op,
sqlrepr(self.expr2, db))
 File "/usr/lib/python2.3/site-packages/sqlobject/converters.py",
line 187, in sqlrepr
   return converter(obj, db)
 File "/usr/lib/python2.3/site-packages/sqlobject/converters.py",
line 98, in StringLikeConverter
   assert 0, "Database %s unknown" % db
AssertionError: Database None unknown

That's a strange bug, because it's failing for a really simple query
(almost identical to the one in the tutorial for SQLObject). I'm using
the latest SVN code. It does not matter if StrCol is a UnicodeCol or
StringCol. It's strange because it works for ints, but doesn't work
when the argument is a string. I'm trying to trace it down, but that's
the first time I'm trying to understand SQLBuilder internals, so I
thought that it would be good to report it.

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

[SQLObject] Bug on SQLBuilder when using strings in the query

[Carlos R. <car...@gm...>]

Hello all, 

I'm trying to use a fairly complex query with SQLObject, and was
having a problem with a "AssertionError: Database None unknown" error
message. I've traced it down to this:

class Catalog(SQLObject):
    item_code = StrCol(length=15, notNone=True, alternateID=True)
    item_descr = StrCol(length=40, default='')

print Catalog.q.item_code == 1   # works!
print Catalog.q.item_code == '001'  # does not work!

cribeiro@fiona:~/work/c-l-py $ python test-select-sql-object.py
(catalog.item_code = 1)
Traceback (most recent call last):
  File "test-select-sql-object.py", line 15, in ?
    print Catalog.q.item_code == '001'
  File "/usr/lib/python2.3/site-packages/sqlobject/sqlbuilder.py",
line 157, in __str__
    return self.__sqlrepr__(None)
  File "/usr/lib/python2.3/site-packages/sqlobject/sqlbuilder.py",
line 222, in __sqlrepr__
    return "(%s %s %s)" % (sqlrepr(self.expr1, db), self.op,
sqlrepr(self.expr2, db))
  File "/usr/lib/python2.3/site-packages/sqlobject/converters.py",
line 187, in sqlrepr
    return converter(obj, db)
  File "/usr/lib/python2.3/site-packages/sqlobject/converters.py",
line 98, in StringLikeConverter
    assert 0, "Database %s unknown" % db
AssertionError: Database None unknown

That's a strange bug, because it's failing for a really simple query
(almost identical to the one in the tutorial for SQLObject). I'm using
the latest SVN code. It does not matter if StrCol is a UnicodeCol or
StringCol. It's strange because it works for ints, but doesn't work
when the argument is a string. I'm trying to trace it down, but that's
the first time I'm trying to understand SQLBuilder internals, so I
thought that it would be good to report it.


-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

Re: [SQLObject] date time column default now()

[Brian R. <br...@se...>]

On Dec 13, 2004, at 4:11 PM, Ian Bicking wrote:

> Brian Ray wrote:
>> I need help using SQLObject. I am trying to override a column 
>> attribute without actually sending an argument.
>> Is there a way I can get a time stamp functionality out of my date 
>> time column default?
>> ...
>> from mx.DateTime import *
>> class table(SQLObject):
>>     timestamp = DateTimeCol(default=now())
>
> I think you want:
>
>     timestamp = DateTimeCol(default=now)
>
> If you pass a function as the default, that function is called 
> immediately before actually using it

Great! And I see where this concept may be useful in other places, so i 
added to wiki:

http://wiki.sqlobject.org/timestamp.html

Hope it's ok.

Re: [SQLObject] date time column default now()

[Ian B. <ia...@co...>]

Brian Ray wrote:
> I need help using SQLObject. I am trying to override a column attribute 
> without actually sending an argument.
> 
> Is there a way I can get a time stamp functionality out of my date time 
> column default?
> 
> ...
> from mx.DateTime import *
> class table(SQLObject):
>     timestamp = DateTimeCol(default=now())

I think you want:

     timestamp = DateTimeCol(default=now)

If you pass a function as the default, that function is called 
immediately before actually using it.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

[SQLObject] date time column default now()

[Brian R. <br...@se...>]

I need help using SQLObject. I am trying to override a column attribute 
without actually sending an argument.

Is there a way I can get a time stamp functionality out of my date time 
column default?

...
from mx.DateTime import *
class table(SQLObject):
	timestamp = DateTimeCol(default=now())
...

The problem I am having is that the stamp fills in at the time when the 
object was initialized, not when a new row is added.  This is the 
expected behavior.

I was thinking the fix was adding something like:

...
	def _set_timestamp(self):
		return now()
...

but, I get: "_set_timestamp() takes exactly 1 argument (2 given)"


After removing the default, I also tried:

...
    def _set_timestamp(self):
       self._SO_set_timestamp(now())
...

but, I get: "did not get expected keyword argument 'timestamp'"

I see in the manual where I can pass a value to these and then do 
something with this value. However, I would much rather not pass 
anything and get a time stamp in each row, once when created and maybe 
in a separate field once when updated. Any help, much appreciated. 

Re: [SQLObject] Releases and versioning.

[Alan K. <sql...@xh...>]

[Alan Kennedy]
 >> But I see that the tagging is not used in that repository.

[Ian Bicking]
 > No.  There's no deep intention behind it.  OTOH, tagging vs. branching
 > seems like a CVS concept, though maybe still a useful metaphor.  A tag
 > is just a branch that we agree not to update.

and

 > Sure, I'm open to suggestions on the subversion layout.  At some point
 > I'll probably refactor it some, at the same time that I move to http
 > (Apache, instead of the standalone server).

Thanks for the reply Ian.

I think the fact that we're even having a discussion about the merits of 
"branches" vs. "tags" and whether they're useful or not is indicative of 
a problem of confusing legacy terminology.

But, subversion makes it easier to use whatever terminology is 
appropriate to the scenario, so I think it best to avoid this kind of 
semantic confusion and name things for what they explicitly are.

Therefore, I would propose to use a "releases" url to hold releases. 
Then use "branches" for the "traditional" meaning of the term, which is 
to be parallel active development trees, e.g. the "inheritance" branch.

Then getting release 0.5.2 or 0.6.1,  would become

svn co svn://colorstudy.com/releases/SQLObject/RELEASE_0_5_2
svn co svn://colorstudy.com/releases/SQLObject/RELEASE_0_6_1

Checking out a copy of the inheritance branch would become

svn co svn://colorstudy.com/branches/SQLObject/inheritance

Also, it should be possible to restrict permission on the "releases" 
subtree, meaning you could restrict permission to make releases, but 
still allow development activity on other sub-urls.

Just one suggestion.

Cheers,

Alan.

Re: [SQLObject] Releases and versioning.

[Ian B. <ia...@co...>]

Alan Kennedy wrote:
> I'm seeking some clarity on the versioning and release mechanism for 
> SQLObject.
> 
> On visiting the sqlobject.org site, various parts of the site refer to 
> the current version as 0.5.2. I.e. the front page has a list of "recent 
> releases", in which 0.5.2 is the most recent.

Damn.  I made changes to the website, uploaded them, but forgot to 
commit them, then uploaded other incremental changes from another site.

> But I know that 0.6 is available, because I checked it out of svn myself 
> :-) Or did I?
> 
> I thought that 0.6 was the latest version, but on looking at the News 
> page on the site, that lists 0.6.1 as the most recent release.
> 
> http://www.sqlobject.org/docs/News.html

Yeah... I guess that should be called "svn head", which will become 
0.6.1.  But somehow 0.6.2 got in my version of the News.  Huh.

> Also, the SQLObject documentation page is the one for 0.6.1.
> 
> http://sqlobject.org/docs/SQLObject.html

And I reuploaded the docs when I made some fixes (mostly which had 
nothing to do with 0.6.1).

> But I can't see anywhere on the site or on sourceforge to actually 
> download 0.6.1. The most recent release on sourceforge is 0.6.0. (I'm 
> uncertain as to whether "SQLObject-0.6-1.noarch.rpm" contains 0.6.0 or 
> 0.6.1?)
> 
> http://sourceforge.net/project/showfiles.php?group_id=74338
> 
> So I thought I'd go to the definitive source, the ColorStudy svn 
> repository. First, I tried to see if there were any svn tags set
> 
> prompt> svn ls svn://colorstudy.com/tags/SQLObject/
> svn: URL non-existent in that revision
> 
> But I see that the tagging is not used in that repository.

No.  There's no deep intention behind it.  OTOH, tagging vs. branching 
seems like a CVS concept, though maybe still a useful metaphor.  A tag 
is just a branch that we agree not to update.

> Then I tried
> 
> prompt>svn ls svn://colorstudy.com/branches/SQLObject/
> 
> Which got the following list
> 
> 0.5/
> 0.6/
> 
> I'm presuming that the latter contains the 0.6 code.
> 
> But which release? 0.6.0? 0.6.1? Or the head revision? It's confusing, 
> without going through the checkin logs in detail to see which version is 
> which.

There will be a 0.6.1 branch when that is released.

> Am I the only one who finds this confusing?
> 
> Lastly, I have a suggestion to make: use svn tagging to tag/label a 
> release so that it is easy to retrieve.
> 
> For example, if the 0.6.1 release had been tagged, then I could check 
> out the 0.6.1 release with a command like
> 
> svn co svn://colorstudy.com/tags/SQLObject/RELEASE_0_6_1
> 
> Or something like that. SVN tagging is a simple and powerful mechanism 
> to manage this sort of issue (I think RCS and CVS call it "labelling").
> 
> I like to use fixed versions of software, rather than the "bleeding 
> edge", straight form the repository: it makes testing, installation and 
> environment management *so* much easier.

Sure, I'm open to suggestions on the subversion layout.  At some point 
I'll probably refactor it some, at the same time that I move to http 
(Apache, instead of the standalone server).

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

[SQLObject] Re: Releases and versioning.

[Alan K. <sql...@xh...>]

[Carlos Ribeiro]
> Having tags to mark intermediate releases would be helpful -- it would
> encourage the habit of creating mini-releases more frequently (0.6.1,
> 0.6.2...). But reorganizing the repository may be a little bit
> difficult at this point -- lots of people already have copies pointing
> to the current structure. But it can be done, anyway, if there"s
> enough perceived advantage in doing it. (I think it does :-)

I agree with the sentiment of making minor releases easier to find and 
manage.

There should be no need to reorganise the repository: simply use the 
existing "branches" directory. For example, when 0.6.2 is released, it 
could be stored under

svn://colorstudy.com/branches/SQLObject/0.6.2/

Though people might get confused by the use of branches to contain releases.

Regards,

Alan.