sqlobject-discuss

[SQLObject] Preparing for 0.4

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

I'm planning on putting 0.4 out before too long.  I've added Styles and
taken out the lazy fetching.  There are a bunch of updates I want/need
to do to the documentation, but besides that I don't have any big plans
-- stuff like constraints (on the Python side) will wait.  

I might have missed something, though.  Is there any unresolved issues
that should be dealt with before 0.4?


-- 
Ian Bicking  ia...@co...  http://colorstudy.com
4869 N. Talman Ave., Chicago, IL 60625  /  773-275-7241
"There is no flag large enough to cover the shame of 
 killing innocent people" -- Howard Zinn

[SQLObject] change to Col.py

[Bud P. B. <bu...@si...>]

Ian, 

I double checked the patches I sent and found that you didn't apply
one of my fixes in CVS:

Col.py, in _extraSQL:  instead of 

  if self.unique or self.alternateID:
    result.append('UNIQUE')

it would be better to state:
    
  if self.unique or self.alternateID:
    result.append('UNIQUE')
    result.append('NOT NULL')

At least in my understanding of PostgreSQL, UNIQUE does not seem to
imply NOT NULL.  

--b

Re: [SQLObject] change to Col.py

[Bud P. B. <bu...@si...>]

Actually, a better (or more correct fix) would be the following:

def _extraSQL(self):
  result = []
  if self.notNull or self.alternateID:
    result.append('NOT NULL')
  if self.unique or self.alternateID:
    result.append('UNIQUE')
  return result

This is the correct way that alternateID implies NOT NULL.

--b

On Tue, 22 Apr 2003 12:31:56 +0200
"Bud P. Bruegger" <bu...@si...> wrote:

> Ian, 
> 
> I double checked the patches I sent and found that you didn't apply
> one of my fixes in CVS:
> 
> Col.py, in _extraSQL:  instead of 
> 
>   if self.unique or self.alternateID:
>     result.append('UNIQUE')
> 
> it would be better to state:
>     
>   if self.unique or self.alternateID:
>     result.append('UNIQUE')
>     result.append('NOT NULL')
> 
> At least in my understanding of PostgreSQL, UNIQUE does not seem to
> imply NOT NULL.  
> 
> --b
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
> 


/-----------------------------------------------------------------
| Bud P. Bruegger, Ph.D. 
| Sistema (www.sistema.it)
| Via U. Bassi, 54
| 58100 Grosseto, Italy
| +39-0564-411682 (voice and fax)
\-----------------------------------------------------------------

Re: [SQLObject] Preparing for 0.4

[Peter W. <pw-...@te...>]

On Tuesday, April 22, 2003, at 01:16  PM, Ian Bicking wrote:

> I'm planning on putting 0.4 out before too long.  I've added Styles and
> taken out the lazy fetching.  There are a bunch of updates I want/need
> to do to the documentation, but besides that I don't have any big plans
> -- stuff like constraints (on the Python side) will wait.  
>
> I might have missed something, though.  Is there any unresolved issues
> that should be dealt with before 0.4?

A small addition to the docs  - in the section 'Selecting Multiple 
Objects' adding a quick note about .select('all') could be useful, I 
found this in the example and pretty sure its not mentioned anywhere in 
either the SQLObject or SQLBuilder docs.

--
peter w.

Re: [SQLObject] Preparing for 0.4

[Peter W. <pw-...@te...>]

On Tuesday, April 22, 2003, at 01:16  PM, Ian Bicking wrote:

> I might have missed something, though.  Is there any unresolved issues
> that should be dealt with before 0.4?
>

I've been doing some more work with SQLite and come up with the 
following that might be useful to have.

class SQLiteConnection(DBAPI):

     def __init__(self, dsn, autoCommit=1, **kw):
         assert sqlite, 'sqlite module cannot be found'
         self.dsn = dsn  # full path to sqlite-db-file
         if not autoCommit and not kw.has_key('pool'):
             # Pooling doesn't work with transactions...
             kw['pool'] = 0
         # use only one connection for sqlite - supports multiple 
cursors per connection
         self._conn = sqlite.connect(self.dsn)
         DBAPI.__init__(self, **kw)

     def makeConnection(self):
         return self._conn

The autoCommit=1 and the pooling conditional is just copied directly 
from PostgresConnection, SQLite supports transactions so I presume that 
for the same reasons this is needed.

I changed how it deals with getting a connection so that code like the 
following will work without needing to turn the results into lists, 
really any code where you have database access inside loops like this 
not just deletes.

users = User.select('all')
for i in users:
     for ul in u.userLocations:
         ul.destroySelf()

SQLite + Python only supports one connection at a time. In my 
understanding the select loop should be able to run in a different 
connection to the delete as SQLite only locks when changing the db. I'm 
trying to find out exactly where the oddness is happening.

Can you see any problems with doing this?

--
peter w.

Re: [SQLObject] Preparing for 0.4

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

On Tue, 2003-04-22 at 23:48, Peter Wilkinson wrote:
[snip]
> The autoCommit=1 and the pooling conditional is just copied directly 
> from PostgresConnection, SQLite supports transactions so I presume that 
> for the same reasons this is needed.

Okay, applied to CVS.

> I changed how it deals with getting a connection so that code like the 
> following will work without needing to turn the results into lists, 
> really any code where you have database access inside loops like this 
> not just deletes.
> 
> users = User.select('all')
> for i in users:
>      for ul in u.userLocations:
>          ul.destroySelf()
> 
> SQLite + Python only supports one connection at a time. In my 
> understanding the select loop should be able to run in a different 
> connection to the delete as SQLite only locks when changing the db. I'm 
> trying to find out exactly where the oddness is happening.
> 
> Can you see any problems with doing this?

Yes, that seems to work.  I don't know enough about the SQLite and
concurrency to really know, but if it works then its fine with me.

I wonder if it works okay with transactions...

  Ian

Re: [SQLObject] Preparing for 0.4

[David M. C. <da...@da...>]

On Mon, Apr 21, 2003 at 10:16:12PM -0500, Ian Bicking wrote:

> I'm planning on putting 0.4 out before too long.  I've added Styles and
> taken out the lazy fetching.  There are a bunch of updates I want/need
> to do to the documentation, but besides that I don't have any big plans
> -- stuff like constraints (on the Python side) will wait.  
> 
> I might have missed something, though.  Is there any unresolved issues
> that should be dealt with before 0.4?

There's a bogus couple of lines (544-5) in the 
DBConnection.PosgresConnection.guessClass method I submitted:

        elif t.startswith('datetime'):
	    return Col.DateTimeCol, {}

that were just copied from the old guessClass method.  Since Postgres
doesn't have antyhing that matches 'datetime' AFAIK, this doesn't do
anything.  I haven't had a chance to look at how date handling is done, so I
don't know if changing this to something like:

      elif t.startswith('date') or t.startswith('time'):
      	   return Col.DateTimeCol, {}
	   
is useful or not.

Dave

Re: [SQLObject] Preparing for 0.4

[Mike H. <th...@bi...>]

On Tue, Apr 22, 2003 at 10:11:33PM -0700, David M. Cook wrote:
> There's a bogus couple of lines (544-5) in the 
> DBConnection.PosgresConnection.guessClass method I submitted:
> 
>         elif t.startswith('datetime'):
> 	    return Col.DateTimeCol, {}
> 
> that were just copied from the old guessClass method.  Since Postgres
> doesn't have antyhing that matches 'datetime' AFAIK, this doesn't do
> anything.  I haven't had a chance to look at how date handling is done, so I
> don't know if changing this to something like:

In PostgreSQL < 7.3, 'datetime' is the same as 'timestamp'.  In
PostgreSQL >= 7.3, it has been depreicated.

-- mikeh

Re: [SQLObject] Preparing for 0.4

[David M. C. <da...@da...>]

On Wed, Apr 23, 2003 at 07:36:39AM -0500, Mike Hostetler wrote:

> In PostgreSQL < 7.3, 'datetime' is the same as 'timestamp'.  In
> PostgreSQL >= 7.3, it has been depreicated.

Ah, so it does do something for a lot of people (e.g. RH 8 has PG 7.2 AFAIK),
and it looks like it does the right thing in that case:

class DateTimeCol(Col):

    # 3-03 @@: provide constraints; right now we let the database
    # do any parsing and checking.  And DATE and TIME?

    def _mysqlType(self):
        return 'DATETIME'

    def _postgresType(self):
        return 'TIMESTAMP'
	
Dave

Re: [SQLObject] Preparing for 0.4

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

Yes, I believe Bud pointed this out to me.

It's annoying, because TIMESTAMP in MySQL is funny, but Postgres'
TIMESTAMP is like MySQL's DATETIME.  On a related note, this kind of
makes me want to stick with StringCol (vs. TextCol)...

On Wed, 2003-04-23 at 07:58, David M. Cook wrote:
> Ah, so it does do something for a lot of people (e.g. RH 8 has PG 7.2 AFAIK),
> and it looks like it does the right thing in that case:
> 
> class DateTimeCol(Col):
> 
>     # 3-03 @@: provide constraints; right now we let the database
>     # do any parsing and checking.  And DATE and TIME?
> 
>     def _mysqlType(self):
>         return 'DATETIME'
> 
>     def _postgresType(self):
>         return 'TIMESTAMP'
> 	
> Dave
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

Re: [SQLObject] Preparing for 0.4

[Frank B. <fb...@fo...>]

Hallo,
Ian Bicking hat gesagt: // Ian Bicking wrote:

> I'm planning on putting 0.4 out before too long.  I've added Styles and
> taken out the lazy fetching.  

Does taking out lazy fetching mean, that changed objects now will have
immediatly visible changes even under Webware? 

I still cannot solve my problem, where objects, that are referenced
by other classes, don't have their changes visible. 

A simple example is an editable Tip of the Day app, where a Day can
have multiple tips.

The model is: 

class Tip(SQLObject):
	_columns = [ 
		IntCol("dateID"), foreignKey='Date'), 
		StringCol("text") ]
		
class Date(SQLObject):
	_columns = [ 
		DateTimeCol("start"), 
		DateTimeCol("end") ]
	_joins   = [MultipleJoin("Tip")]


Now my Page has an action to change the Tip of a Day

	def changeT(self):
		req  = self.request()
		id   = req.value('id', None)
		text = req.value('text', None)
		t = Tip(id)
		t.text = text
		self._msg = '''Changed: %s ''' % t.id
		self.writeBody()

It also has a "listTips" area, whose pseudo code looks like this:

for day in Date.select("all"):
	prettyPrint(day)
	for tip in day.tips:
		prettyPrint(tip)

Now this last printing of the tips does not reflect changes done in
"changeT" until the AppServer is restarted. This is really driving me
nuts... 

ciao
-- 
 Frank Barknecht                               _ ______footils.org__

Re: [SQLObject] Preparing for 0.4

[Frank B. <fb...@fo...>]

Hallo,
Frank Barknecht hat gesagt: // Frank Barknecht wrote:

> Ian Bicking hat gesagt: // Ian Bicking wrote:
> 
> > I'm planning on putting 0.4 out before too long.  I've added Styles and
> > taken out the lazy fetching.  
> 
> Does taking out lazy fetching mean, that changed objects now will have
> immediatly visible changes even under Webware? 

To reply to myself: changes are visible now with current cvs. Thanks a
lot...

ciao
-- 
 Frank Barknecht                               _ ______footils.org__