sqlobject-discuss — All things SQLObject-related

[SQLObject] Adding description field to col.py

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

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.

- Samir

Re: [SQLObject] SQLBuilder / Update

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

sw...@fr... wrote:
> How can I use sqlbuilder.Update() to simply update sqlobjects given   
> their ID ?

I forgot that was even in there.  sqlbuilder.Update is more for generic 
construction of SQL queries, it's not intended to be used with SQLObject 
as a whole.  sqlbuilder preceded SQLObject, which is where that came from.

   Ian

[SQLObject] SQLBuilder / Update

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

Hi,

How can I use sqlbuilder.Update() to simply update sqlobjects given  =20
their ID ?

I have some methods like:

   def updateBandImageWithID(self, bandID, imageFile):
       # And to avoid fetching the Band Object, something like:
       r =3D Update(Band.q,{'cover_file': imageFile},
                  where=3DBand.q.id =3D=3D bandID)

But I get errors about connection set to None. I don't want to pass
Band objects to methods. I've read the SQLBuilder doco and code, but
couldn't make Update() work.

Am I wrong trying to do such things ?

PS: I'm using 0.5.2's version. But planning to switch to svn trunk


--
Philippe Normand

[SQLObject] Re: select() causes webware/threaded application to die (part II)

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

On 31 Mar 2004, Ian Bicking said:
> Okay, the problem is fixed in the repository now 
> (svn://colorstudy.com/branches/SQLObject/0.5).  It turned out the 
> connections were being returned to the pool multiple times, once when 
> the iterator was exhausted and a second time when the iterator was 
> deleted.  Blech.  Anyway, should be fixed now.  I'll make another 
> release shortly as long as there aren't any problems.  Kind of sucks to 
> make another release to fix the problem the last release was supposed 
> to fix.
> 
> The 0.6 branch is being updated as well.

Awesome! :D

Thanks for figuring this out. I was kinda stuck. :)

Re: [SQLObject] select() causes webware/threaded application to die (part II)

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

Okay, the problem is fixed in the repository now 
(svn://colorstudy.com/branches/SQLObject/0.5).  It turned out the 
connections were being returned to the pool multiple times, once when 
the iterator was exhausted and a second time when the iterator was 
deleted.  Blech.  Anyway, should be fixed now.  I'll make another 
release shortly as long as there aren't any problems.  Kind of sucks to 
make another release to fix the problem the last release was supposed 
to fix.

The 0.6 branch is being updated as well.

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

[SQLObject] SQL Type of primary keys

[Daniel E B. <da...@li...>]

Is it possible to specify the type of the primary key? I am using
postgres and I'd like to usde bigserial and not serial as the primary
key type.

Dan
-- 
And if cynics ridicule freedom, ridicule community...if ``hard nosed
realists'' say that profit is the only ideal...just ignore them, and use
copyleft all the same.
      -- RMS

[SQLObject] Ordering results from a related join

[Martin O. <ma...@ga...>]

Hello,

Is there a "clean" way to order the results from a related join e.g. 
order team.players by their names where the Team table has a related 
join on the Players table ?

Martin 

Re: [SQLObject] How can return Yes/No for bool

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

On Tue, 2004-03-30 at 13:20, Samir Patel wrote:
> Is there anyway in sqlobject to return __repr__ of boolCol to Yes/No instead 
> of True/False?


You could use a get overrider:

class Food(SQLObject):
    madeFromPeanutButter = BoolCol()

    def _get_madeFromPeanutButter(self):
        if self._SO_get_madeFromPeanutButter():
            return "Yes"
        else:
            return "No"

And you'd probably want a setter, too - you can probably make a better one than this.

    def _set_madeFromPeanutButter(self, value):
        if value in ("no","No","No", False, 0, "Non"):
            self._SO_set_madeFromPeanutButter(False):
        else:
            self._SO_set_madeFromPeanutButter(True)

[SQLObject] How can return Yes/No for bool

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

Is there anyway in sqlobject to return __repr__ of boolCol to Yes/No instead 
of True/False?

[SQLObject] Re: Quixote (0.7a3) ihook error when importing sqlobject 0.6

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

Found problem. I need to do "from sqlobect import *" before enable_ptl().
- Samir

On Monday 29 March 2004 03:17 pm, Samir Patel wrote:
> This is very strange error. I was running quixote application with
> sqlobject 0.5.2 which works great on both windows and linux. I then
> downloaded svn version of sqlobject (0.6), modify my application and it run
> perfect under linux. However when I try to run same application under
> windows, it cannot import sqlobject.
>
> I trace back problem and it boils down to importing sqlobject. If I comment
> out "from sqlobject import *" from __init__.py file, it runs fine otherwise
> it throws following error. If I run it outside of quixote, it runs fine
> (And as I said before it runs fine in  linux).
>
> ***************************************************************************
>*******************
>
> Traceback (most recent call last):
>   File
> "C:Python23\lib\site-packages\Pythonwin\pywin\framework\scriptutils.py",
> line 310, in RunScript
>     exec codeObject in __main__.__dict__
>   File "C:\Python23\Lib\site-packages\motor\motorService.py", line 20, in ?
>     publisher = Publisher('motor')
>   File "C:\Python23\lib\site-packages\quixote\publish.py", line 106, in
> __init__
>     self.root_namespace = _get_module(root_namespace)
>   File "C:\Python23\lib\site-packages\quixote\publish.py", line 32, in
> _get_module
>     __import__(name)
>   File "C:\Python23\Lib\ihooks.py", line 398, in import_module
>     q, tail = self.find_head_package(parent, str(name))
>   File "C:\Python23\Lib\ihooks.py", line 434, in find_head_package
>     q = self.import_it(head, qname, parent)
>   File "C:\Python23\Lib\ihooks.py", line 489, in import_it
>     m = self.loader.load_module(fqname, stuff)
>   File "C:\Python23\lib\site-packages\quixote\ptl_import.py", line 111, in
> load_module
>     return ihooks.ModuleLoader.load_module( self, name, stuff)
>   File "C:\Python23\Lib\ihooks.py", line 274, in load_module
>     m = self.hooks.load_package(name, filename, file)
>   File "C:\Python23\Lib\ihooks.py", line 174, in load_package
>     return imp.load_module(name, file, filename, ("", "", PKG_DIRECTORY))
>   File "C:\Python23\lib\site-packages\motor\__init__.py", line 3, in ?
>     from sqlobject import *
>   File "C:\Python23\Lib\ihooks.py", line 398, in import_module
>     q, tail = self.find_head_package(parent, str(name))
>   File "C:\Python23\Lib\ihooks.py", line 439, in find_head_package
>     q = self.import_it(head, qname, parent)
>   File "C:\Python23\Lib\ihooks.py", line 489, in import_it
>     m = self.loader.load_module(fqname, stuff)
>   File "C:\Python23\lib\site-packages\quixote\ptl_import.py", line 111, in
> load_module
>     return ihooks.ModuleLoader.load_module( self, name, stuff)
>   File "C:\Python23\Lib\ihooks.py", line 274, in load_module
>     m = self.hooks.load_package(name, filename, file)
>   File "C:\Python23\Lib\ihooks.py", line 174, in load_package
>     return imp.load_module(name, file, filename, ("", "", PKG_DIRECTORY))
>   File "/usr/lib/python2.3/site-packages/sqlobject/__init__.py", line 7, in
> ? ImportError: cannot import name connectionForURI

[SQLObject] Re: select() causes webware/threaded application to die (part II) - 1 attachment

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

On 30 Mar 2004, Ian Bicking said:
> Which patch are we talking about?  There's no open patches on the SF 
> patch manager.  If there's something out there that fixes this, I'm 
> sure we can get it into the code.

It was a quick fix you posted on the mailing list. Here's the original 
message you posted:

> Hmm...
> 
> Bah, DBConnection.iterSelect is dumb.  It shouldn't be written like it 
> is.  Right now it looks like:
> 
>      def iterSelect(self, select):
>          return self._runWithConnection(self._iterSelect, select, self,
>                                         False)
> 
> Which means the connection is returned to the pool immediately when the 
> generator is returned, then reused when it shouldn't be, and worse it 
> can be returned to the pool another time if the select results are 
> exhausted.  It should look like:
> 
>      def iterSelect(self, select):
>          conn = self.getConnection()
>          return self._iterSelect(conn, select, self, False)
> 
> This isn't quite right either, as the connection will only be returned 
> if you exhaust the select.  _iterSelect should be broken out into an 
> object that returns the connection on __del__.  Anyway, this iterSelect 
> should resolve your concurrency problems for the moment (I haven't 
> tested it, though; report back if it works)
> 
>    Ian

This only works for 0.5.1, of course, cause you added the Iterator() 
class in 0.5.2 and 0.6, but the Iterator() class has the same bug as the 
unpatched 0.5.1.

Here's my SQLObject Hammerer again, incase you wanna replicate and track 
down this baby. :)

begin 644 sqlobject_hammer.py
M9G)O;2!344Q/8FIE8W0@:6UP;W)T("H*(U]?8V]N;F5C=&EO;E]?(#T@4&]S
M=&=R97-#;VYN96-T:6]N*&AO<W0])VQO8V%L:&]S="<L('5S97(])W1E<W0G
M+"!P87-S=V0])W1E<W0G+"!D8CTG=&5S="<I"E]?8V]N;F5C=&EO;E]?(#T@
M37E344Q#;VYN96-T:6]N*'5S97(])W1E<W0G+"!P87-S=V0])W1E<W0G+"!D
M8CTG=&5S="<I"B-?7V-O;FYE8W1I;VY?7R`]($UY4U%,0V]N;F5C=&EO;BAU
M<V5R/2=T97-T)RP@<&%S<W=D/2=T97-T)RP@9&(])W1E<W0G+"!D96)U9STQ
M*0II;7!O<G0@<F%N9&]M"@IN=6UP965P<R`](#(*;G5M=VAA8VME<G,@/2`R
M,`IW:&%C:W,@/2`U,#`*"F-L87-S(%!E97!S*%-13$]B:F5C="DZ"B`@;F%M
M92`](%-T<FEN9T-O;"AD969A=6QT/2)(86YK,"!/)TUA;&QE>2(I"B`@86=E
M(#T@26YT0V]L*&1E9F%U;'0],3`I"@ID968@;6%K97!E97!S*"DZ"B`@<')I
M;G0@(DUA:VEN9R!P965P<RXN+B(*("!P<FEN="`G+2<J-3`*("!0965P<RYD
M<F]P5&%B;&4H:69%>&ES=',]5')U92D*("!0965P<RYC<F5A=&5486)L92@I
M"B`@9F]R(&D@:6X@<F%N9V4H,"QN=6UP965P<RDZ"B`@("!P<FEN="`B<&5E
M<"(L(&D*("`@('!E97`@/2!0965P<RYN97<H(&YA;64](DAA;FLE9"!/)TUA
M;&QE>2(E<F%N9&]M+G)A;F1I;G0H,2PY.3DI+`H@("`@("`@("`@("`@("`@
M("`@("`@86=E/7)A;F1O;2YR86YD:6YT*#$L-3`P*2`I"B`@"B`@<')I;G0@
M(B5D('!E97!S(&-R96%T960N+BXB("4@*&DK,2D*"@ID968@=VAA8VMI="AI
M9"DZ"B`@("!T(#T@,`H@("`@=VAI;&4@="`\('=H86-K<SH*("`@("`@("!T
M("L](#$*("`@("`@("!P965P<R`](%!E97!S+G-E;&5C="@I"B`@("`@("`@
M9F]R(&-O=6YT+"!P965P(&EN(&5N=6UE<F%T92AP965P<RDZ"B`@("`@("`@
M("`@('!A<W,*("`@("`@("!P<FEN="`B=VAA8VME<B`C)60@?"!I=&5R871I
M;VXZ("5D("AR96%D("5D(')E8V]R9',I(B`E("AI9"P@="P@8V]U;G0K,2D*
M("`@("`@("!D96P@<&5E<',*("`@("`@("!D96P@<&5E<`H@("`@("`@(`H@
M("`@<')I;G0@(G=H86-K97(@(R5D("T^($9)3DE32$5$(2(@)2!I9`H@("`*
M9&5F(&UA:6XH*3H*("`@(&EM<&]R="!T:')E860*("`@(&UA:V5P965P<R@I
M"@H@("`@<')I;G0*("`@('!R:6YT(")72$%#2TE.1R$A(2(*("`@('!R:6YT
M("(](BHU,`H*("`@(&9O<B!T(&EN(')A;F=E*&YU;7=H86-K97)S*3H*("`@
M("`@("!T:')E860N<W1A<G1?;F5W7W1H<F5A9"AW:&%C:VET+"`H="PI*0H@
M("`@=VAI;&4@+3$Z"B`@("`@("`@<&%S<PH@("`@"FEF(%]?;F%M95]?(#T]
9("=?7VUA:6Y?7R<Z"B`@("!M86EN*"D*"HD!
`
end

Re: [SQLObject] select() causes webware/threaded application to die (part II)

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

On Mar 29, 2004, at 4:51 AM, Scott Russell wrote:
> 0.5.2 brings this problem back, and the patch to fix it from 02-Mar-04
> no longer applies.  I had to roll back to 0.5.1 and apply that fix to
> use select without the AppServer punting.

Which patch are we talking about?  There's no open patches on the SF 
patch manager.  If there's something out there that fixes this, I'm 
sure we can get it into the code.

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

Re: [SQLObject] Re: Re: select() causes webware/threaded application to die (part II)

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

I suppose I shall enter my own bit here:

We also have a few apps that initiate several webware/XMLRPC calls per web
request to a page (XMLRPC from a flash app), would hang webware until we
applied this fix.

The glitch (as I thought was documented with the patch?) is that the connection
is returned by runWithConnection after the first value, so subsequent
iteration may use the connection which has been subsequently been given to
another request.

- Luke

Quoting Chris Gahan <ch...@il...>:

> Scott Russell <sc...@to...> wrote:
>> I've got a public multiuser scenario where I build dynamic calendars
>> from slightly complex queries - that's the hammering that I'm killing
>> it with.
>
> Ah, I see...
>
>> Have you tried moving back to 0.5.1 and applying the patch from the
>> date mentioned below?   I'll go catch up on your concurrency thread.
>
> Oh my god! That fixes it completely! I can hammer it insanely and it
> doesn't flinch!
>
> This has to be a simple glitch in the new code then, which I don't
> compeltely understand. :)
>
>
>
> -------------------------------------------------------
> 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



--
The Pursuit of Counterfactual Histories

[SQLObject] Re: Re: select() causes webware/threaded application to die (part II)

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

Scott Russell <sc...@to...> wrote:
> I've got a public multiuser scenario where I build dynamic calendars
> from slightly complex queries - that's the hammering that I'm killing
> it with.

Ah, I see...
 
> Have you tried moving back to 0.5.1 and applying the patch from the
> date mentioned below?   I'll go catch up on your concurrency thread.

Oh my god! That fixes it completely! I can hammer it insanely and it 
doesn't flinch!

This has to be a simple glitch in the new code then, which I don't 
compeltely understand. :)

Re: [SQLObject] Re: select() causes webware/threaded application to die (part II)

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

On Mon, 2004-03-29 at 19:00, Chris Gahan wrote:
>  
> > Am I the only one using select(), or does my use somehow trigger this
> > problem?
> 
> I'm having the same problem. You can read the thread entitled 
> "Concurrency issues..." if you wanna see what I've been experiencing.
> 
> I think the reason other people don't complain about this is that they 
> don't hammer SQLObject as badly as we do. :)
> 
> The reason my code hammers SQLObject is because I use my database to 
> store image metadata to display a bunch of images on a webware page, and 
> every image on the page gets returned by a webware servlet, which will 
> result in like 10 servlets all getting called at once, each one does an 
> SQLObject query.
> 
> I temporarily fixed my problem by setting Webware to only use one thread, 
> but that's not "optimal". :)

I've got a public multiuser scenario where I build dynamic calendars
from slightly complex queries - that's the hammering that I'm killing it
with.

Have you tried moving back to 0.5.1 and applying the patch from the date
mentioned below?   I'll go catch up on your concurrency thread.

[SQLObject] Hooking into insert, update, delete, etc.

[Daniel E B. <da...@li...>]

Hi all. I am new to SQLObject and I just read through the docs and
started digging into the code some although my knowlege of meta classes
and such needs work. My situation is I have 6 or so fields on the ends
of all my data tables: createdOn, createdBy, modifiedOn, modifiedBy,
owner and tag. What I did in the past was write wrapper functions for
insert, update, delete, etc. that would get the info from the current
session and would add additional where clauses using these fields and/or
update these fields so that I would only be passing the sql that did
what I wanted to do at the time and then the wrapper would automatically
add stuff to the sql to handle these fields. My question is how can I
use SQLObject to update/query using these fields but have it be
transparent to the rest of my sql objects. Ideally I would like this
functionality to be factored out into a base class which derives from
SQLObject. I should then be able to use this as a base for the rest of
my data objects and get the same sort of "transparency" that I had with
my simple wrapper functions. I am not sure if that would work as there
is no stand alone table that has these fields.

I know that SQLObject uses properties, etc. but I was hoping I could get
a nudge in the right direction before I dug too deeply into SQLObject
code. Thanks for reading.

Dan
-- 
And if cynics ridicule freedom, ridicule community...if ``hard nosed
realists'' say that profit is the only ideal...just ignore them, and use
copyleft all the same.
      -- RMS

[SQLObject] Re: select() causes webware/threaded application to die (part II)

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

Scott Russell <sc...@to...> wrote in 
news:1080557484.8209.97.camel@glimmer:

> 0.5.2 brings this problem back, and the patch to fix it from 02-Mar-04
> no longer applies.  I had to roll back to 0.5.1 and apply that fix to
> use select without the AppServer punting.
> 
> Am I the only one using select(), or does my use somehow trigger this
> problem?

I'm having the same problem. You can read the thread entitled 
"Concurrency issues..." if you wanna see what I've been experiencing.

I think the reason other people don't complain about this is that they 
don't hammer SQLObject as badly as we do. :)

The reason my code hammers SQLObject is because I use my database to 
store image metadata to display a bunch of images on a webware page, and 
every image on the page gets returned by a webware servlet, which will 
result in like 10 servlets all getting called at once, each one does an 
SQLObject query.

I temporarily fixed my problem by setting Webware to only use one thread, 
but that's not "optimal". :)

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

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

Ian Bicking <ia...@co...> wrote in news:7916C560-7CEA-11D8-9093-
000...@co...:
> On Mar 23, 2004, at 2:31 AM, Chris Gahan wrote:
>> Can anybody suggest why MySQL would think I was executing an 
>> "out-of-sync" command? Could it be that the cursor needs to be
>> "closed" before being returned to the DB? Maybe the object is getting
>> deleted mid-iteration, and a connection containing partially-
>> iterated cursor is being returned to the pool?
>
> Have you run the problem code with debugging on?  The output should 
> list connection IDs along with the commands, so you should be able to 
> see if there's something out of sync.

I have, actually, but it doesn't yield much insight. It's exactly what 
you'd figure was happening from looking at the code: queries get executed 
on the connections, then you suddenly get a database exception when one 
thread tries to execute a query on a connection that was just returned to 
the pool.

I think the pool needs some debugging messages if we want to figure out 
what's happening. I'm pretty sure the exception is caused by the state of 
the underlying conneciton to the database for the pooled connection. 
Maybe the last command isn't getting committed before the connection gets 
put back into the pool, or maybe the cursor isn't getting closed... or 
maybe the cursor being closed needs to be committed?!? :) I dunno. I'm 
not too familiar with Python DB stuff.

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.

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.

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.

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).

What do you think? I'd be willing to help overhaul it if you think it's 
worthwhile. The main reasons I can see for doing this is to make both the 
*Connection and pooling code simpler and more robust.

[SQLObject] Quixote (0.7a3) ihook error when importing sqlobject 0.6

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

This is very strange error. I was running quixote application with sqlobject 
0.5.2 which works great on both windows and linux. I then downloaded svn 
version of sqlobject (0.6), modify my application and it run perfect under 
linux. However when I try to run same application under windows, it cannot 
import sqlobject. 

I trace back problem and it boils down to importing sqlobject. If I comment 
out "from sqlobject import *" from __init__.py file, it runs fine otherwise 
it throws following error. If I run it outside of quixote, it runs fine (And 
as I said before it runs fine in  linux).

**********************************************************************************************

Traceback (most recent call last):
  File 
"C:Python23\lib\site-packages\Pythonwin\pywin\framework\scriptutils.py", line 
310, in RunScript
    exec codeObject in __main__.__dict__
  File "C:\Python23\Lib\site-packages\motor\motorService.py", line 20, in ?
    publisher = Publisher('motor')
  File "C:\Python23\lib\site-packages\quixote\publish.py", line 106, in 
__init__
    self.root_namespace = _get_module(root_namespace)
  File "C:\Python23\lib\site-packages\quixote\publish.py", line 32, in 
_get_module
    __import__(name)
  File "C:\Python23\Lib\ihooks.py", line 398, in import_module
    q, tail = self.find_head_package(parent, str(name))
  File "C:\Python23\Lib\ihooks.py", line 434, in find_head_package
    q = self.import_it(head, qname, parent)
  File "C:\Python23\Lib\ihooks.py", line 489, in import_it
    m = self.loader.load_module(fqname, stuff)
  File "C:\Python23\lib\site-packages\quixote\ptl_import.py", line 111, in 
load_module
    return ihooks.ModuleLoader.load_module( self, name, stuff)
  File "C:\Python23\Lib\ihooks.py", line 274, in load_module
    m = self.hooks.load_package(name, filename, file)
  File "C:\Python23\Lib\ihooks.py", line 174, in load_package
    return imp.load_module(name, file, filename, ("", "", PKG_DIRECTORY))
  File "C:\Python23\lib\site-packages\motor\__init__.py", line 3, in ?                    
    from sqlobject import *
  File "C:\Python23\Lib\ihooks.py", line 398, in import_module
    q, tail = self.find_head_package(parent, str(name))
  File "C:\Python23\Lib\ihooks.py", line 439, in find_head_package
    q = self.import_it(head, qname, parent)
  File "C:\Python23\Lib\ihooks.py", line 489, in import_it
    m = self.loader.load_module(fqname, stuff)
  File "C:\Python23\lib\site-packages\quixote\ptl_import.py", line 111, in 
load_module
    return ihooks.ModuleLoader.load_module( self, name, stuff)
  File "C:\Python23\Lib\ihooks.py", line 274, in load_module
    m = self.hooks.load_package(name, filename, file)
  File "C:\Python23\Lib\ihooks.py", line 174, in load_package
    return imp.load_module(name, file, filename, ("", "", PKG_DIRECTORY))
  File "/usr/lib/python2.3/site-packages/sqlobject/__init__.py", line 7, in ?
ImportError: cannot import name connectionForURI

[SQLObject] select() causes webware/threaded application to die (part II)

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

0.5.2 brings this problem back, and the patch to fix it from 02-Mar-04
no longer applies.  I had to roll back to 0.5.1 and apply that fix to
use select without the AppServer punting.

Am I the only one using select(), or does my use somehow trigger this
problem?

[SQLObject] Invitation to join the Self_promote group

[Self_promote m. <Sel...@ya...>]

Hello sql...@li...,

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

By joining Self_promote, you will be able to exchange
messages with other group members, store photos and files, 
coordinate events and more.

This invitation will expire in 7 days.

Here's an introductory message from wti...@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=RIliOPjtzau9Y8syKyxNa_NIBIw&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 Self_promote 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=92js5g0DVejJLhXl8CKGmqq8QtCbAaMXm6x2vVpbhvCRdAyUQWxJ_bFfS4Wwtklsiga8BGlWJUi_zvmK4Ig-p3-cLwE

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

 

Re: [SQLObject] Requesting WIKI on website for SQLObject

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

On Mar 25, 2004, at 11:31 PM, David McNab wrote:
> Ian Bicking wrote:
>> On Mar 25, 2004, at 6:54 PM, David McNab wrote:
>>> How would the SQLObject project admins feel about putting up a wiki 
>>> on the sqlobject.sf.net website?
>> Sure, that'd be great.  Do you have any interest in setting it up?  I 
>> can give you the access as well.
>
> Guess this makes sense, since I'm building the pyweb.gui framework 
> which makes extensive use of SQLObject, so I guess I'll be part of the 
> SQLObject 'furniture' for some time to come.

Cool!

> I exist on sourceforge as 'davidmcnab'.
>
> What I'd have in mind is installing the MoinMoin wiki system into the 
> SQLObject htdocs dir (actually, 
> /home/groups/s/sq/sqlobject/htdocs/wiki), and populating it with a few 
> basic headings, and linking to it from the main SQLObject home page.
>
> Would you be happy with this?

Yes, that sounds about right.  The SQLObject website as it exists now 
is in the Subversion repository.  I can give you access to that too.  
But the Wiki can probably stay outside of the repository.  Or not, I'm 
not sure.

But maybe we should wait on this a bit -- there was some work on making 
ReST work in MoinMoin during some PyCon sprinting, and I'd really like 
to be able to use ReST, and have other people use ReST, so that content 
can migrate into and out of the other documentation.  Anyway, I can try 
to figure out where that updated version exists.  (Probably in the 
Docutils sandbox...)

> leave this line intact so your email gets through my junk mail filter

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

Re: [SQLObject] Overcoming SQLOBject's non-OO behaviour

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

On Mar 26, 2004, at 6:14 PM, David McNab wrote:
> While I've got SQLObject now working nicely with my pyweb.gui web 
> framework in CGI mode and standalone server mode, SQLObject's 
> behaviour under mod_apache is giving me some trouble.
>
> Even when creating/using whole new connection objects, and using these 
> in completely separate table classes, SQLObject seems to be storing 
> stuff globally, and not keeping all its state info encapsulated within 
> each connection object.

I'm not entirely clear what state information you're referring to.  It 
may simply be a bug.

> IMO, this is very non-OO behaviour - when one creates a new connection 
> object, and uses this object in building table classes, SQLObject's 
> behaviour should be the same regardless of whether any classes 
> accessing the same tables have already been created in the same 
> process.

*But*, the class resolution is a bit more complicated, and is stored 
more-or-less globally.

In SQLObject classes don't really belong to connections.  In reality 
they usually do, but it's not unusual to create the class first 
(otherwise createTable wouldn't be useful), or to define the class and 
make the connection configurable, and generally to bind the connection 
to the class after the class is created.  I don't think it would be the 
right decision to make tables/classes belong to connections.

Because of the string->class resolution, we have to store names 
globally, and they have to be unique.  The class registries allow for 
separate sets of classes with overlapping names.

> My workaround is to impose a rule on the user, that within any given 
> apache process, no more than one pyweb.gui application may access the 
> same table. But as you can see, this is a pretty unacceptable 
> limitation.
>
> Is there any way of causing SQLObject to 'clean its slate' and 'forget 
> everything'? If so, what's the best way?

There's several -- some of which probably aren't documented -- but it 
depends on just what information you're thinking of.

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

Re: [SQLObject] .get(int) vs. .get(string)

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

On Mar 26, 2004, at 3:41 AM, Hendrik Mans wrote:
> Hello everyone,
>
> ---cut---
>>>> from Crop.Data.User import User
>>>> u1 = User.get(1)
>>>> u2 = User.get('1')
>>>> u1 == u2
> False
> ---cut---
>
> Is this by design? I was expecting SQLObject to either return the same
> object instance *or* raise an exception when passing the string.

Well... not design.  I guess it's a known problem, though I had 
forgotten about it for a while.  If you do something like:

class User(SQLObject):
     def _init(self, id, connection=None):
         id = int(id)
         return SQLObject._init(self, id, connection=connection)

I believe that should resolve it for you.  Ultimately the id type 
should become part of a column specifier, like other columns are 
specified, but there's some other issues involved with that that I 
haven't gotten around to.

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

[SQLObject] Overcoming SQLOBject's non-OO behaviour

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

Hi,

While I've got SQLObject now working nicely with my pyweb.gui web 
framework in CGI mode and standalone server mode, SQLObject's behaviour 
under mod_apache is giving me some trouble.

Even when creating/using whole new connection objects, and using these 
in completely separate table classes, SQLObject seems to be storing 
stuff globally, and not keeping all its state info encapsulated within 
each connection object.

IMO, this is very non-OO behaviour - when one creates a new connection 
object, and uses this object in building table classes, SQLObject's 
behaviour should be the same regardless of whether any classes accessing 
the same tables have already been created in the same process.

My workaround is to impose a rule on the user, that within any given 
apache process, no more than one pyweb.gui application may access the 
same table. But as you can see, this is a pretty unacceptable limitation.

Is there any way of causing SQLObject to 'clean its slate' and 'forget 
everything'? If so, what's the best way?

Thanks in advance for your help

Cheers
David