sqlobject-discuss — All things SQLObject-related

Re: [SQLObject] connection URIs

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

Philippe Normand wrote:
> On Fri, Apr 16, 2004 at 01:48:29PM -0400, jws...@ra... wrote:
> 
>>I'm switching to 0.6 and it's not obvious how to setup the new style URI's.
>>Do I need to assign the URI to __connection__ , 
>>_connection , or conn ?
> 
> Use __connection__ like in 0.5 .. Table._connection can also be used
> as before. The only thing which changed is the way to assign it:
> 
> __connection__ = dbconnection.connectionForURI(dbURI)

Yes, that's the best way to do it.  You can use a string alone in some 
places as well (e.g., __connection__ = dbURI), but I think I'm going to 
take that out because it can't be made to work everywhere you might 
specify a connection (while connectionForURI() will work).

   Ian

Re: [SQLObject] connection URIs

[Philippe N. <sw...@fr...>]

On Fri, Apr 16, 2004 at 01:48:29PM -0400, jws...@ra... wro=
te:
> I'm switching to 0.6 and it's not obvious how to setup the new style URI'=
s.
> Do I need to assign the URI to __connection__ ,=20
> _connection , or conn ?
>=20

Use __connection__ like in 0.5 .. Table._connection can also be used
as before. The only thing which changed is the way to assign it:

__connection__ =3D dbconnection.connectionForURI(dbURI)


--=20
Philippe Normand

[SQLObject] connection URIs

[<jws...@ra...>]

I'm switching to 0.6 and it's not obvious how to setup the new style URI's.
Do I need to assign the URI to __connection__ , 
_connection , or conn ?

Re: [SQLObject] _get_ function

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

Samir Patel wrote:
> Thanks for your reply Ian. If I create it as a method than I will lose power 
> of retriving data by just calling field name. Currently I solve it this way: 
> When I need to pass a value to a _get_ method, I am adding a different field 
> to that object and initialzing it with value I want to pass. Then in my _get_ 
> method I am checking whether that object has this new field, If it has this 
> new field, I use that value like a paramenter value otherwise I am using 
> default value. This way I can still retrive my field data by simply calling 
> field name.

Using attribute access is just a convenience, and you really shouldn't 
use it if it's not appropriate.  This is a case where it's not 
appropriate -- if something requires a parameter, it should be a method. 
  Otherwise you are hiding the parameter in another attribute, which 
will definitely lead to future confusion.

   Ian

Re: [SQLObject] _get_ function

[Samir P. <sp...@ci...>]

Thanks for your reply Ian. If I create it as a method than I will lose power 
of retriving data by just calling field name. Currently I solve it this way: 
When I need to pass a value to a _get_ method, I am adding a different field 
to that object and initialzing it with value I want to pass. Then in my _get_ 
method I am checking whether that object has this new field, If it has this 
new field, I use that value like a paramenter value otherwise I am using 
default value. This way I can still retrive my field data by simply calling 
field name.

On Wednesday 14 April 2004 09:14 pm, you wrote:
> Samir Patel wrote:
> > I need some ideas on solving this problem.
> >
> > I have int field  daysOpen in my SQLObject which is not set by user.  I
> > wrote a _get_daysOpen which calculates days difference between other
> > field (birthday) from todays date. Now I like to calculate days
> > difference from user defined date instead of today. How can I do this?
>
> It will have to be a method, like daysOpenTo(date)

[SQLObject] New wiki

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

wiki.sqlobject.org is set up, same software (and server) as 
wiki.webwareforpython.org

There's no content on it at all, even an intro page, but it's there if 
anyone feels like adding anything.  At some point I'll put in the 
necessary links as well from the homepage and elsewhere.

   Ian

Re: [SQLObject] _get_ function

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

Samir Patel wrote:
> I need some ideas on solving this problem.
> 
> I have int field  daysOpen in my SQLObject which is not set by user.  I wrote 
> a _get_daysOpen which calculates days difference between other field 
> (birthday) from todays date. Now I like to calculate days difference from 
> user defined date instead of today. How can I do this? 

It will have to be a method, like daysOpenTo(date)

[SQLObject] _get_ function

[Samir P. <sp...@ci...>]

I need some ideas on solving this problem.

I have int field  daysOpen in my SQLObject which is not set by user.  I wrote 
a _get_daysOpen which calculates days difference between other field 
(birthday) from todays date. Now I like to calculate days difference from 
user defined date instead of today. How can I do this? 

[SQLObject] Invitation to join the WTI_self_promotion group

[WTI_self_promotion m. <WTI...@ya...>]

Hello sql...@li...,

wt...@ya... has invited to join the WTI_self_promotion group
hosted by Yahoo! Groups, a free, easy-to-use community service.

By joining WTI_self_promotion, you will be able to receive
email announcements, share photos and files, coordinate events and more.

NOTE: This is an announcement or newsletter group, so only the group
moderator may post messages.

This invitation will expire in 7 days.

Here's an introductory message from wt...@ya...:
------------------------------------------------------------------------

You are invited to join "Self Promotion" at our Yahoo Group

If you are webmaster, internet marketing or business owner who 
would like to promote your website through search engines & directory.
This group you can find international seach engine list which
provide pages which easy to submit manually.
(we select only FREE submissions)

Come & join us.
 

------------------------------------------------------------------------

JOIN NOW, IT'S EASY: 

1) Go to the Yahoo! Groups site by clicking on this link:
   http://groups.yahoo.com/i?i=cCWDKio56-y14azf9P9M9g_f8A0&e=sqlobject-discuss%40lists%2Esf%2Enet 

  (If clicking doesn't work, "Cut" and "Paste" the line above into your 
   Web browser's address bar.)

-OR-

2) REPLY to this email by clicking "Reply" and then "Send"
   in your email program

If you do not wish to join the WTI_self_promotion group, please
ignore this invitation.

Report abuse:
------------------------------------------------------------------------
Yahoo! Groups is a free service that allows you to stay in touch with 
friends and family or meet new people who share your interests. 
Yahoo! Groups values your privacy. It is a violation of our service 
rules for Groups members to abuse this invitation feature. If you feel 
this has happened, please notify us:
http://help.yahoo.com/help/us/groups/abuse/index.html

You may also change your email preferences to stop receiving group 
invitations in the future. To do so, please go here:
http://groups.yahoo.com/s?tag=1a7fhfcLamFY9DTcM9VJZPBbvDLMfMJ-KlpvPquyybrRURFtkOdH3FLTn5zz9T3lNSQO6nEE5Khm9DZMZvckEy-LhBuoZgs

Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

 

[SQLObject] Accumulate Select results

[Philippe N. <sw...@fr...>]

Hi,
 
Here is the patch resulting from previous thread called 'SUM'. I've
coded the behaviour for count() and sum() methods. But max(), min()
and friends should be trivial too :)

There also are few tests in SelectTest t-unit (may there be more, but
this is the basis for now).

-- 
Philippe Normand

Re: [SQLObject] basic help

[Andrew S. G. <asg...@uc...>]

The reference to the "Mostly Live CVS Tarball" is here -> 
http://sqlobject.org/#download'

Thanks for all of the help.. I check out the sources through the 
subversion repository,

-Andy

Ian Bicking wrote:

> Andrew S. Garbutt wrote:
>
>> I am just starting out with SQLObject.  It looks like a really nice 
>> package that i can use to map some complex relations.  However, in 
>> starting out i ran into some trouble.  The code that I used follows 
>> this message, and matches the provided code in the documentation..  
>> The error occurs when i try p = Person(firstName="Jose", 
>> lastName="Galvez").  I am using Python 2.3.3 on windows with 
>> SQLObject's Mostly Live CVS Tarball.   Any help would be greatly 
>> appreciated.
>
>
> Whoops, sorry, the mostly live tarball isn't very live at all anymore. 
> Where did you see the reference to it? (so I can remove it)
>
> You should use a subversion checkout, which is truly live:
>
>   svn co svn://colorstudy.com/trun/SQLObject
>
> (None of the half-day-old anon SourceForge CVS stuff anymore)
>
>   Ian
>

Re: [SQLObject] basic help

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

Andrew S. Garbutt wrote:
> I am just starting out with SQLObject.  It looks like a really nice 
> package that i can use to map some complex relations.  However, in 
> starting out i ran into some trouble.  The code that I used follows this 
> message, and matches the provided code in the documentation..  The error 
> occurs when i try p = Person(firstName="Jose", lastName="Galvez").  I am 
> using Python 2.3.3 on windows with SQLObject's Mostly Live CVS 
> Tarball.   Any help would be greatly appreciated.

Whoops, sorry, the mostly live tarball isn't very live at all anymore. 
Where did you see the reference to it? (so I can remove it)

You should use a subversion checkout, which is truly live:

   svn co svn://colorstudy.com/trun/SQLObject

(None of the half-day-old anon SourceForge CVS stuff anymore)

   Ian

Re: [SQLObject] basic help

[Scott R. <sc...@to...>]

Person.new(firstName="Jose", lastName="Galvez")

You were missing the .new ...

On Wed, 2004-04-07 at 14:50, Andrew S. Garbutt wrote:
> I am just starting out with SQLObject.  It looks like a really nice 
> package that i can use to map some complex relations.  However, in 
> starting out i ran into some trouble.  The code that I used follows this 
> message, and matches the provided code in the documentation..  The error 
> occurs when i try p = Person(firstName="Jose", lastName="Galvez").  I am 
> using Python 2.3.3 on windows with SQLObject's Mostly Live CVS 
> Tarball.   Any help would be greatly appreciated.
> 
> -Andy
> 
> [TRACEBACK]
> raceback (most recent call last):
>   File "<interactive input>", line 1, in ?
> TypeError: __new__() got an unexpected keyword argument 'lastName'
> 
> 
> [CODE]
> 
> from SQLObject import *
> 
> __connection__ = MySQLConnection(host='169.237.122.232',
>                                  db='pydo',
>                                  user='root',
>                                  passwd='jerrymouse'
>                                  )
> 
> class Person(SQLObject):
>     firstName = StringCol()
>     middleInitial = StringCol(length=1, default=None)
>     lastName = StringCol()
> 
> 
> Person.createTable()
> 
> 
> p = Person(firstName="Jose", lastName="Galvez")
> 
> print p
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

[SQLObject] basic help

[Andrew S. G. <asg...@uc...>]

I am just starting out with SQLObject.  It looks like a really nice 
package that i can use to map some complex relations.  However, in 
starting out i ran into some trouble.  The code that I used follows this 
message, and matches the provided code in the documentation..  The error 
occurs when i try p = Person(firstName="Jose", lastName="Galvez").  I am 
using Python 2.3.3 on windows with SQLObject's Mostly Live CVS 
Tarball.   Any help would be greatly appreciated.

-Andy

[TRACEBACK]
raceback (most recent call last):
  File "<interactive input>", line 1, in ?
TypeError: __new__() got an unexpected keyword argument 'lastName'


[CODE]

from SQLObject import *

__connection__ = MySQLConnection(host='169.237.122.232',
                                 db='pydo',
                                 user='root',
                                 passwd='jerrymouse'
                                 )

class Person(SQLObject):
    firstName = StringCol()
    middleInitial = StringCol(length=1, default=None)
    lastName = StringCol()


Person.createTable()


p = Person(firstName="Jose", lastName="Galvez")

print p

[SQLObject] Re: [Webware-discuss] Choosing a wiki

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

Hallo,
Shayne ONeill hat gesagt: // Shayne ONeill wrote:

> I'd certainly take no offence if a reST one is used :) That little wiki I
> whacked together is admitedly a little messy and probably useless without
> the auth the rest of my software provides. :) Whats the PyDiddy port like?

PyDiddy is my port of PikiPiki to be a Webware-WikiWiki. (Do I sound
like a Teletubby...? ) 

You can see it in action on my site: http://footils.org/cms/wiki/ and
get the code at webware-sandbox.sf.net 

It is a very simple, but well working Wiki, that we also use in our
intranet for several time now. 

But it isn't a very well structured piece of software, the renderer is
hard to extend and it's not template-based. But it is very stable and
generally JustWorks (tm) all the time.

It even has a crude user authentication! But I wouldn't recommend it
for the Webware-site.

ciao
-- 
 Frank Barknecht                               _ ______footils.org__

Re: [SQLObject] SUM

[Philippe N. <sw...@fr...>]

Ian Bicking wrote:

> Looks okay.  I'd like to have tests to go with any new code, though.  
> If tests/test.py is too hairy for you, a test in the form of an 
> interactive script will do.
>
Ok, I'll have a look to the tests stuff

> Also, it occurs to me that these are all about accumulation -- count, 
> sum, max, min, and no doubt others.  It might be nice to generalize 
> this, like SelectResult.accumulate(expression), where sum looks like:
>
> def sum(self, column):
>     return self.accumulate(sqlbuilder.func.SUM(column))
>
> ... though sum should probably also for a string column; accumulate 
> doesn't have to check for that -- though if it is passed a string it 
> should interpret it as a SQL expression, so you could do 
> selectResult.accumulate('SUM(a_column)')
>
Yes this is a good idea. I was thinking about it when copying count() to 
make sum() (the code is quite the same)
I'll produce a new patch (with tests ;) this evening

phil

[SQLObject] Re: [Webware-discuss] Choosing a wiki

[Shayne O. <sh...@pe...>]

I'd certainly take no offence if a reST one is used :) That little wiki I
whacked together is admitedly a little messy and probably useless without
the auth the rest of my software provides. :) Whats the PyDiddy port like?

--
Shayne O'Neill
http://perth.indymedia.org
I know how hard it is for you to put food on your family."
 ----George W. Bush

On Tue, 6 Apr 2004, Ian Bicking wrote:

> Now that we have a server for Webware, we should think about what Wiki
> to use.  Several options have been presented -- Shayne's recent Wiki,
> the Wiki I wrote in the Sandbox, Frank's PyDiddy port (which I had
> quite forgotten about), and maybe a few others (e.g., I have yet
> another Wiki that I didn't put in the Sandbox, that I had been working
> on a couple years ago; no doubt other Webware wikis are out there).
>
> I *really* want reST input, because I think it's good for writing about
> programming, and that's what the Wiki will be about.  So writing code
> blocks and the sort should be easy, which it is in reST.  At the moment
> this means a patched version of MoinMoin, or my sandbox wiki.
>
> I'd also like to move the Cheetah Wiki over, since it's hosted with the
> Webware Wiki right now.  And there was a request for setting up a
> SQLObject Wiki, which I'd also like to put up, because by that time it
> should be easy to add yet another ;)  And they're all related projects.
>   But I think it's okay if they are all separate Wikis in separate Wiki
> namespaces.  They could each be a domain -- wiki.webwareforpython.org,
> wiki.cheetahtemplate.org, wiki.sqlobject.org.
>
> Any thoughts?  Right now I'm inclined to flesh mine out a bit more, and
> keep the pages in plain text files to make the content easy to
> manipulate if we change implementations.
>
> --
> Ian Bicking | ia...@co... | http://blog.ianbicking.org
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Webware-discuss mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webware-discuss
>

[SQLObject] Choosing a wiki

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

Now that we have a server for Webware, we should think about what Wiki 
to use.  Several options have been presented -- Shayne's recent Wiki, 
the Wiki I wrote in the Sandbox, Frank's PyDiddy port (which I had 
quite forgotten about), and maybe a few others (e.g., I have yet 
another Wiki that I didn't put in the Sandbox, that I had been working 
on a couple years ago; no doubt other Webware wikis are out there).

I *really* want reST input, because I think it's good for writing about 
programming, and that's what the Wiki will be about.  So writing code 
blocks and the sort should be easy, which it is in reST.  At the moment 
this means a patched version of MoinMoin, or my sandbox wiki.

I'd also like to move the Cheetah Wiki over, since it's hosted with the 
Webware Wiki right now.  And there was a request for setting up a 
SQLObject Wiki, which I'd also like to put up, because by that time it 
should be easy to add yet another ;)  And they're all related projects. 
  But I think it's okay if they are all separate Wikis in separate Wiki 
namespaces.  They could each be a domain -- wiki.webwareforpython.org, 
wiki.cheetahtemplate.org, wiki.sqlobject.org.

Any thoughts?  Right now I'm inclined to flesh mine out a bit more, and 
keep the pages in plain text files to make the content easy to 
manipulate if we change implementations.

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

Re: [SQLObject] SUM

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

On Apr 5, 2004, at 3:24 PM, Philippe Normand wrote:
> On Sun, Apr 04, 2004 at 04:17:32PM -0500, Ian Bicking wrote:
>> On Apr 4, 2004, at 8:33 AM, Philippe Normand wrote:
>>> How can I use func.SUM() since it can't reside in where condition ?
>>> For COUNT(), there's a way with Table.select().count(). What's the
>>> trick for SUM() ?
>>> I didn't found any Table.select().sum('attribute')
>>
>> You can't really use SUM -- it's also left in sqlbuilder from
>> sqlbuilder's past life as a general query builder.  It would be
>> interesting to add that as a method to SelectResults, like count.
>>
>
> Would this patch answer your request ?

Looks okay.  I'd like to have tests to go with any new code, though.  
If tests/test.py is too hairy for you, a test in the form of an 
interactive script will do.

Also, it occurs to me that these are all about accumulation -- count, 
sum, max, min, and no doubt others.  It might be nice to generalize 
this, like SelectResult.accumulate(expression), where sum looks like:

def sum(self, column):
     return self.accumulate(sqlbuilder.func.SUM(column))

... though sum should probably also for a string column; accumulate 
doesn't have to check for that -- though if it is passed a string it 
should interpret it as a SQL expression, so you could do 
selectResult.accumulate('SUM(a_column)')

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

[SQLObject] pythonClassToDBTable and dbTableToPythonClass

[Minh L. <mi...@to...>]

The pythonClassToDBTable and dbTableToPythonClass in Style.py are written as
below:

 def pythonClassToDBTable(self, className):
        return className[0].lower() \
               + mixedToUnder(className[1:])

    def dbTableToPythonClass(self, table):
        return table[0].upper() \
               + underToMixed(table[1:])

They produces some unexpected results, for example "TOrder" is converted to
"torder" rather than "t_order".

Could this be changed to:

 def pythonClassToDBTable(self, className):
     return mixedToUnder(className)

 def dbTableToPythonClass(self, table):
      m = underToMixed(table)
      return m[0].upper() + m[1:]

Thanks

[SQLObject] Metadata container

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

There's a bunch of metadata right now that is being stored in various 
instance variables, all ad hoc like, and with no introspective 
interfaces.  I'd like to consolidate these into a single object/class 
that is separated from the SQLObject class.  This way I don't have to 
worry about name clashes, and I don't feel like every added little 
interface will be polluting people's classes.  (Though most of the 
public methods that are there now will remain methods of the SQLObject 
subclasses, just like they are now)  So I'm looking for feedback on how 
that should work.

There's actually two kinds of metadata -- the metadata for the class, 
like a list of columns, and the metadata for the instance.  There's not 
a lot of instance metadata at this point, but it would include things 
like if the object was dirty, or obsolete (deleted), etc.  There's also 
a bunch of internal bookkeeping-style attributes that SQLObject uses 
which are on a per-instance level.

So... how should these look?  I've been thinking of something like:

SQLObject.sqlmeta.columns: dictionary of columns
.table: DB-name of table
.store: the DBConnection object (kind of)
.cacheColumns: true if we cache columns (vs. fetching them on each 
access)
.obsolete: true if the object has been deleted (but not garbage 
collected yet)

and so on.  In turn column objects will have a better public interface 
as well, so you can look at the particulars of a column.

But it's a little confusing, because some of these belong to the class 
and some to the instance.  This is fine now, because some are class 
variables and some are instance variables, and instances get all the 
class methods, but can also shadow them and other stuff (though that's 
used only in small ways).

We could do that now if SQLObject.sqlmeta was a class, and 
aSQLObjectInstance.sqlmeta was an instance of that class... but is that 
weird or confusing?  Should it be SQLObject.SQLMeta and 
aSQLObjectInstance.sqlmeta?  That doesn't seem much better.

I'm also thinking that you will subclass this metadata class to add 
many options, but again that could seem weird.  E.g.:

class Contact(SQLObject):
     class sqlmeta(SQLObject.sqlmeta):
         table = 'contact_table'
         cacheInstances = False
     name = StringCol()
     ...

Column objects also become descriptors, and so are part of the class 
directly -- in the end it's less funny metaclass stuff, but they will 
probably call on this sqlmeta object to do most of the work.

I'm thinking that this could clean up the code a great deal, but I'm 
still not entirely sure how this should look, so I'm looking for 
feedback.

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

Re: [SQLObject] Re: Re: Concurrency issues...

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

I just wanted to reply to some of the things you brought up in general 
design terms.

On Mar 29, 2004, at 5:55 PM, Chris Gahan wrote:
> One issue that this whole debacle has brought to my attention, however,
> is the design of DBAPI. It's not very flexible, and I think it could be
> improved.

First, no arguments here.  Well, it's reasonably flexible for what it 
does, which is abstracting out database-specific issues.  It could use 
more factoring, including moving things like pooling into separate, 
generic modules.

> Right now, the pooling code (in the DBAPI class) and the database-
> abstraction layer (in the *Connection classes) are all bundled together
> in a single class, and I think they should be separated.
>
> Why don't we simplify the *Connection classes so that they're only
> responsible for creating connections to the DB and executing SQL
> commands. This would make it easier to handle exceptions (like
> "connection timed out", which currently kills your program if it
> happens). The connection object could catch that specific exception, 
> and
> try to re-establish the connection, allowing the calling function to
> continue on its merry way! :D
>
> Then, separating the pool out could be done by creating a
> "ConnectionFactory" class. It could be subclassed depending on the
> behaviour you wanted. To use it, you'd just create an instance of it 
> and
> assign it to SQLObject's _connection attribute.

Oh no, not factories!

> Default factories could be: SimpleConnectionFactory (which just 
> creates a
> new connection every time, and if too many connections are open, it'll
> wait until some connections got closed before returning new 
> connections),
> and of course, the PooledConnectionFactory.

Oh no, not subclasses!

> Then, SQLObject could also include (or people could write their own)
> special-purpose factories. For example: a factory that always returns 
> the
> same connection to a specific Webware servlet, effectively giving each
> servlet its own DB connection (you could implement it by instantiating
> the factory with the servlet's .__hash__() as a parameter, or 
> something).

Taking the particular issue that spawned this discussion, the problem 
was a bug, not a lack of potential for customization.  It can certainly 
be argued that the bug was more likely to exist because of the coupled 
nature of the code involved.  But the solution was to fix it, it 
definitely *wasn't* to make it possible to customize the code so as to 
avoid the bug.  And I think that's what would happen in this model, 
where people would be carrying around their own customizations to the 
code, each person with their own problematic corner cases.

I want SQLObject to work correctly without too much effort.  If there's 
weird issues in some case, I think SQLObject should try to do the right 
thing for everyone.  In most cases this is quite possible.  If it's not 
possible, we should try to look for the sensible set of choices that we 
should support -- not every possible choice, but just the ones that 
have real use cases.  Then we should distill that into some sort of 
option, something that can be easily explained and documented, 
including descriptions of when you will care about the option and how 
you should choose.  I don't want to make SQLObject flexible enough that 
you simply give the user the tools to fix the problem on their own -- I 
think that's burdensome.  (It brings to mind this article: 
http://www.linuxworld.com/story/44251.htm)

And of course, the typical option should be the one that requires no 
thought at all from the user -- i.e., the default.  Unless the typical 
option would be broken for some situation, particularly broken in a way 
that causes bad bugs (e.g., lost data, incorrect data, concurrency 
issues, etc) -- in that case we have to force the user to make an 
explicit choice, and do what we can to make that bug more explicit 
(which might just mean putting in an assert statement).

So from this perspective, I'm definitely opposed to encouraging lots of 
subclasses and factories.  I am enthusiastic about robust, explicit, 
documented modules (just documented in the docstring, nothing fancy), 
and I'm very open to factoring classes like DBAPI into several modules.

That still leaves open the issue of passing in parameters to these 
'hidden' modules and classes, such as if you want to control the pool, 
or one of the caches, which are usually created by SQLObject on behalf 
of the user.  I'm open to suggestions -- but the current situation 
where the SQLObject or DBConnection class has to know what options to 
pass through isn't that bad (even though it does imply some coupling, 
in that everytime you add an option to the cache or pool object you'll 
have to update the SQLObject or DBConnection class).

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

Re: [SQLObject] Adding description field to col.py

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

On Apr 3, 2004, at 3:43 PM, Samir Patel wrote:
> In class SOCol, does it make any sense to add desc argument with 
> following:
>
> if desc:
>     self.desc = desc
> else:
>     self.desc = name
>
> I found it quite useful in creating web page. For ex. field
> fname can have description "First Name" which can be used in creating 
> web
> forms.

I am thinking about ways to change column definitions right now, and 
one thing is to turn any keyword arguments to the constructor into 
attributes, so this would fit into this fairly easily.

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

Re: [SQLObject] SUM

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

On Apr 4, 2004, at 8:33 AM, Philippe Normand wrote:
> How can I use func.SUM() since it can't reside in where condition ?
> For COUNT(), there's a way with Table.select().count(). What's the 
> trick for SUM() ?
> I didn't found any Table.select().sum('attribute')

You can't really use SUM -- it's also left in sqlbuilder from 
sqlbuilder's past life as a general query builder.  It would be 
interesting to add that as a method to SelectResults, like count.

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

[SQLObject] SUM

[Philippe N. <sw...@fr...>]

Hi,

How can I use func.SUM() since it can't reside in where condition ?
For COUNT(), there's a way with Table.select().count(). What's the trick 
for SUM() ?
I didn't found any Table.select().sum('attribute')

Philippe