sqlobject-discuss — All things SQLObject-related

[SQLObject] ezSqlObject convenience wrapper

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

Hi,

I've just put up a module called EzSqlObject, which wraps SQLObject's 
connection, table and results classes, and adds a few conveniences:

*  .tables attribute in connection objects, lists out the tables in
    the database
*  .columns attribute in table objects, lists the columns in the table
*  automatic retrieval of existing table structure from database (if
    not provided as a table class)
*  tables of a database available as attributes of connection object
*  Can fetch individual rows from a table or resultset via array index
*  automatic logging
*  dump() method in connection, table and results objects
*  len() works for table and results objects
*  doQuery() method for connection objects

www.freenet.org.nz/python/ezsqlobject

Hope someone finds it as handy as it is for me.

Cheers
David

--

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

Re: [SQLObject] Escaping/Quoting

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

Scott Russell wrote:
> Is there an abstracted way to escape values so I can feel safe when
> constructing complex select statements, regardless of backend?

self.sqlrepr(value)

   Ian

[SQLObject] Escaping/Quoting

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

Is there an abstracted way to escape values so I can feel safe when
constructing complex select statements, regardless of backend?

Re: [SQLObject] Any pending bugs?

[Brad B. <br...@bb...>]

Le mercredi, 3 mars 2004, =E0 00:31 Canada/Eastern, Ian Bicking a =E9crit =
:

> Are there any bug pending that people know about?  I'm planning to=20
> make an 0.5.2 release with the select bug fix.  Brad had something,=20
> but I've forgotten what it was.  On the bug tracker there's only some=20=

> larger feature request kinds of things that won't go in this release.

I checked in a fix related to BoolCol not working.

Daniel Savard has a couple of important bugfixes that need to be=20
checked (with tests :) in before a 0.5.2. One is a bug dealing with=20
direct accessing of the row's oid from SQLObject with the PostgreSQL=20
backend, which becomes unusably slow for large datasets (because, of=20
course, oid's are not indexed by default), and another is a weird=20
problem we found with cloning that causes commits in the middle of=20
transactions.

I've CC'd him in the hope that he'll have a chance to check his work in=20=

before the next 0.5.x release.

--
Brad Bollenbach=

Re: [SQLObject] Form fields and SQLObject

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

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

> You might want to look back through the mailing lists for a thread
> "Looking for selection hints" started by Frank Barknecht around 10/2003.
> He was doing some similar stuff.

Yes, I posted a QueryBuilder.py, which unfortunatly now grew into
quite a custom, application specific monstrosity (I shouldn't have
done this, I know), so I don't have it anymore, but it's still in the
archives here:
http://sourceforge.net/mailarchive/message.php?msg_id=6379871

Also you might want to take a look at another recent archive post,
where I talked with myself about using fulltext indexes on Postgres,
which showed another use case, namely creating your own "LIKE"-like
operators:
http://sourceforge.net/mailarchive/message.php?msg_id=7076046

ciao
-- 
 Frank Barknecht                               _ ______footils.org__

Re: [SQLObject] Form fields and SQLObject

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

mar...@ge... wrote:
> What I would like is to implement a findPerson method that, based on
> the field values incl. any operators - *, <, >, <=, >= and so on, is
> able to perform a proper search and return all matching Person
> objects(rows). I have fiddled around with some inelegant string
> substitution to ugly to post. Especially properties - in this case
> middleInitial - that defaults to None, are troublesome, since an
> empty field is not matched by None.
> 
> Is there a elegant preferably generic solution for the above ? by
> generic I mean somthing that would work irrespective of the specific
> class.

You might want to look back through the mailing lists for a thread
"Looking for selection hints" started by Frank Barknecht around 10/2003.
He was doing some similar stuff.

> I am using Python 2.3 on Windows 2000 and SQLObject 0.5.1.
> 
> Ian Bicking - super cool tool.

Thanks ;)

Cheers,
   Ian

[SQLObject] Re: Form fields and SQLObject

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

mar...@ge... wrote:
> So far I have a findPerson method that looks like this:
> 
> def findPerson(self, id, fn, mi, ln):
> 	persons = Person.select(
> 						AND(Person.q.firstName.startswith(fn),
> 							Person.q.middleInitial.startswith(mi),
> 							Person.q.lastName.startswith(ln)))
> 	return persons
> [...]
> What I would like is to implement a findPerson method that, based on the field values [...] Is there a elegant preferably generic solution for the above ? by generic I mean somthing that would work irrespective of the specific class.


The best way to do this is, I believe, is not to use those Person.q 
methods. "q" is an SQLBuilder object, which creates regular SQL queries 
when you compare it with strings and stuff. Example:

 >>> fname = "John"
 >>> lname = "Doe"
 >>> AND(Person.q.first_name == fname, person.last_name == lname)
(person.first_name = 'John AND person.last_name = 'Doe')
^^-- the comparison returns that string. Any expression involving 
Person.q's will be converted into a string, which is what the 
Person.select() method actually uses to do the query... its parameter is 
a regular SQL expression (everything after the WHERE part of "SELECT 
whatever FROM table").

So, the best way to do this is to write a clever SQL query that uses the 
"LIKE" operator, which can do fuzzy matches. Here's how it works:

http://www.mysql.com/doc/en/String_comparison_functions.html#IDX1250

It would be something like: Person.select("firstname LIKE %"+fn+"%").
BUT, be careful that the variables you give the SELECT statement (fn, 
mi, etc) are properly quoted and escaped, otherwise someone could hax0r 
your database. :)

[SQLObject] Re: Any pending bugs?

[Rolf <ro...@no...>]

http://sourceforge.net/mailarchive/message.php?msg_id=6805076
http://sourceforge.net/mailarchive/message.php?msg_id=6673437

[SQLObject] Fresh Python for Rotting Web Hosts

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

Hi all,

While working on my (yet another) python-based active web framework, I 
hit on a dilemna.

I want my framework to be deployable on as wide a range of hosts as 
possible, even the < $10/month type hosts (the ones with the latest PHP, 
MySQL, but pitiful or no Python support). Such el-cheapo hosts these 
days often offer 40MB-100MB or more of disk space, but will not upgrade 
their python to later than 2.1 (or worse, 1.5.2), or install needed 
modules (eg MySQLdb).

The dilemna was whether to simply list python2.2 as a requirement (which 
SQLObject needs), but which excludes more than 90% of cheap hosts.

   OR

Switch to Metakit instead, but cope with a bunch of performance-draining 
concurrency issues.

The solution I came up with is a simple recipe for compiling Python 2.3 
or later on a local machine, and uploading the full binary Python tree 
to the host into one's user account (after some radical liposuction to 
trim the Python tree from 50+MB to more like 12MB).

All written up at:
http://www.freenet.org.nz/python/fresh-python-for-rotting-web-hosts.html

Walks the user through the steps of building Python, in such a way as it 
can run within a user's home directory on a cheap host.

So, with this particular problem solved, I've gone firmly in the 
SQLObject direction.

Hope others might find some value in this too.

-- 

Kind regards
David

--

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

[SQLObject] Column default value

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

How do I specify default value for a column?
Following the example in the document, I have
the following code but the generated SQL didn't
have the default value see the debug output.

Thanks

==== Code =====
class MyTable (SQLObject):
    name = StringCol(length=20, notNone=True, default='')
    age = IntCol(notNone=True, default=0)
    dummy = StringCol(length=20, notNone=True, default='DUMMY')
=== End code ====

=== Debug output ===>> 
1/Query   :  CREATE TABLE my_table (
    id INT PRIMARY KEY AUTO_INCREMENT,
    age INT NOT NULL,
    name VARCHAR(20) NOT NULL,
    dummy VARCHAR(20) NOT NULL
)
=== End output =====

Re: [SQLObject] Any pending bugs?

[alexander s. <al...@an...>]

Ian Bicking wrote, at 03.03.2004 7:31:

> Are there any bug pending that people know about?  I'm planning to make 
> an 0.5.2 release with the select bug fix.  Brad had something, but I've 
> forgotten what it was.  On the bug tracker there's only some larger 
> feature request kinds of things that won't go in this release.

http://sourceforge.net/mailarchive/forum.php?thread_id=3644241&forum_id=30269
http://sourceforge.net/tracker/index.php?func=detail&aid=875574&group_id=74338&atid=540674

best wishes,
alex.

[SQLObject] Any pending bugs?

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

Are there any bug pending that people know about?  I'm planning to make 
an 0.5.2 release with the select bug fix.  Brad had something, but I've 
forgotten what it was.  On the bug tracker there's only some larger 
feature request kinds of things that won't go in this release.

(And, as a reminder, anyone who finds a bug should really put it on 
SourceForge, because I will forget about it otherwise)

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

[SQLObject] FIXED: select() causes webware/threaded application to die

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

Presto, seems to hold up just fine now.  Performance appears improved,
as well.

Once again, for anyone searching the mailinglist, in DBConnection.py,

     def iterSelect(self, select):
         conn = self.getConnection()
         return self._iterSelect(conn, select, self, False)

On Tue, 2004-03-02 at 18:17, Ian Bicking wrote:
> Scott Russell wrote:
> > David and Ian:
> > 
> > Yes, (as you'll see in my mail that arrived the same time yours did) it
> > looks like a thread concurrency issue.
> > 
> > If I turn on debugging, the threading test survives many additional
> > threads, but will die eventually. (David, 32 kills it very handily.) 
> > Whether because of some serialization that gets forced during printing,
> > because it slows the process down enough to avoid contention, or some
> > third issue, I can't say.  
> > 
> > Here is a sample run, with 32 threads.  Sometimes it lasts for 30-40
> > queries, sometimes (as seen here) only 3....
> > 
> > $ python Main/TestPage.py
> >  1:Dummy-1/Select  :  SELECT person.id, person.email, person.firstname, person.lastname FROM person WHERE  (person.email = 'xxx') LIMIT 1
> >  1:Dummy-2/Select  :  SELECT person.id, person.email, person.firstname, person.lastname FROM person WHERE  (person.email = 'xxx') LIMIT 1
> >  1:Dummy-3/Select  :  SELECT person.id, person.email, person.firstname, person.lastname FROM person WHERE  (person.email = 'xxx') LIMIT 1
> > Killed
> > 
> > What next?
> 
> Well, it's reusing the same connection each time.  Which it probably 
> shouldn't be -- it can reuse them sometimes, but you'd think it would 
> need to do otherwise sometimes.
> 
> 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
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

Re: [SQLObject] select() causes SQLObject + webware application to die

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

Scott Russell wrote:
> David and Ian:
> 
> Yes, (as you'll see in my mail that arrived the same time yours did) it
> looks like a thread concurrency issue.
> 
> If I turn on debugging, the threading test survives many additional
> threads, but will die eventually. (David, 32 kills it very handily.) 
> Whether because of some serialization that gets forced during printing,
> because it slows the process down enough to avoid contention, or some
> third issue, I can't say.  
> 
> Here is a sample run, with 32 threads.  Sometimes it lasts for 30-40
> queries, sometimes (as seen here) only 3....
> 
> $ python Main/TestPage.py
>  1:Dummy-1/Select  :  SELECT person.id, person.email, person.firstname, person.lastname FROM person WHERE  (person.email = 'xxx') LIMIT 1
>  1:Dummy-2/Select  :  SELECT person.id, person.email, person.firstname, person.lastname FROM person WHERE  (person.email = 'xxx') LIMIT 1
>  1:Dummy-3/Select  :  SELECT person.id, person.email, person.firstname, person.lastname FROM person WHERE  (person.email = 'xxx') LIMIT 1
> Killed
> 
> What next?

Well, it's reusing the same connection each time.  Which it probably 
shouldn't be -- it can reuse them sometimes, but you'd think it would 
need to do otherwise sometimes.

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

Re: [SQLObject] select() causes SQLObject + webware application to die

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

David and Ian:

Yes, (as you'll see in my mail that arrived the same time yours did) it
looks like a thread concurrency issue.

If I turn on debugging, the threading test survives many additional
threads, but will die eventually. (David, 32 kills it very handily.) 
Whether because of some serialization that gets forced during printing,
because it slows the process down enough to avoid contention, or some
third issue, I can't say.  

Here is a sample run, with 32 threads.  Sometimes it lasts for 30-40
queries, sometimes (as seen here) only 3....

$ python Main/TestPage.py
 1:Dummy-1/Select  :  SELECT person.id, person.email, person.firstname, person.lastname FROM person WHERE  (person.email = 'xxx') LIMIT 1
 1:Dummy-2/Select  :  SELECT person.id, person.email, person.firstname, person.lastname FROM person WHERE  (person.email = 'xxx') LIMIT 1
 1:Dummy-3/Select  :  SELECT person.id, person.email, person.firstname, person.lastname FROM person WHERE  (person.email = 'xxx') LIMIT 1
Killed

What next?

Re: [SQLObject] select() causes SQLObject + webware application to die

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

I'm not a webware user, so can only offer a general comment...

Have you tried setting up this thrashing in a non-webware environment?

For instance, you could cook up something quick with the python 
HTTPServer classes (don't forget to add the threading mixin).

Or even, servers aside - cook up multi-threaded programs which 
repeatedly thrash.

One scenario would be a prog which launches 32 threads, each of which 
sit in a loop and thrash.

Another scenario would be a prog which spawns 32 processes, each of 
which do the thrash thing.

Cheers
David


Scott Russell wrote:
> Replying to myself here... Replacing the MySQL connection with a
> postgres one doesn't fix anything - although it seems to last about
> twice as long, maybe 6 seconds under constant hammering.
> 
> How would I even start debugging this?
> 
> On Tue, 2004-03-02 at 14:18, Scott Russell wrote:
> 
>>I've found a situation in which SQLobject makes webware fall over like a
>>straw house...
>>
>>First, a very simple webware servlet:
>>
>>### Start 1 ##
>>from WebKit.Page import Page
>>from SQLObject import *
>>
>>__connection__ = MySQLConnection(host="host", 
>>                                 user="user", 
>>                                 passwd="passwd", 
>>                                 db="db")
>>
>>class Person(SQLObject):
>>    email = StringCol(length=40, default=None)
>>    firstname = StringCol(length=30, default=None)
>>    lastname = StringCol(length=30, default=None)
>>
>>class TestPage(Page):
>>    def writeContent(self):
>>        p = Person(1)        
>>        self.writeln('''Welcome.''')
>>### End 1 ##
>>
>>I hammer and hammer and hammer, and it holds up fine - as hard as I can
>>hit it, it keeps up with me.
>>
>>Now, a Second Servlet: (Only Changing the TestPage class - everything
>>else is the same.)
>>
>>### Start 2 ##
>>class TestPage(Page):
>>    def writeContent(self):
>>        peeps = Person.select(Person.q.email=='xxx')
>>        self.writeln('''Welcome.''')
>>### End 2 ##
>>
>>Once again, this holds up wonderfully.  It never fails, as far as I can
>>tell.  Rock solid.
>>
>>Now, for the bad one.  One more TestPage servlet, this time with an
>>accessor for peeps.
>>
>>### Start 3 ##
>>class TestPage(Page):
>>    def writeContent(self):
>>        peeps = Person.select(Person.q.email=='xxx')
>>        p = peeps[0]
>>        self.writeln('''Welcome''')
>>### End 3 ##
>>
>>This one functions fine, and seems to work fine until the hammering
>>begins, in which case it is guaranteed to fall over within 3 seconds,
>>repeatably, every time.  If used at a reasonable pace, it still falls
>>over, eventually.  Similar tests have found select() to be the culprit -
>>th emore you use it, the faster death occurs.  The strangest issue?  How
>>it dies - I've modified Webkit to print it's exit code.  Normally, it's
>>3, and that tells webkit's shell script to restart it.  When it falls
>>over here, it receives a 137 - which is a "kill -KILL" signal, if I'm
>>correct...
>>
>>Can someone explain this, and hopefully show what I'm doing wrong?  I'm
>>actually supposed to be deploying a site reasonably soon, and can't in
>>it's current state - two users kill it in just over a minute.  I'll be
>>in #webware on irc.freenode.net if anyone wants to compare notes.
>>
>>  - Scott
>>
>>
>>
>>-------------------------------------------------------
>>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>>Build and deploy apps & Web services for Linux with
>>a free DVD software kit from IBM. Click Now!
>>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>>_______________________________________________
>>sqlobject-discuss mailing list
>>sql...@li...
>>https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
> 

--

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

Re: [SQLObject] select() causes SQLObject + webware application to die

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

Scott Russell wrote:
> ### Start 2 ##
> class TestPage(Page):
>     def writeContent(self):
>         peeps = Person.select(Person.q.email=='xxx')
>         self.writeln('''Welcome.''')
> ### End 2 ##

Note that this doesn't do anything.  When you call .select(), it only 
creates a query, it doesn't run it or send anything to the database. 
Only when you iterate or get an index will a query happen.

> Once again, this holds up wonderfully.  It never fails, as far as I can
> tell.  Rock solid.
> 
> Now, for the bad one.  One more TestPage servlet, this time with an
> accessor for peeps.
> 
> ### Start 3 ##
> class TestPage(Page):
>     def writeContent(self):
>         peeps = Person.select(Person.q.email=='xxx')
>         p = peeps[0]
>         self.writeln('''Welcome''')
> ### End 3 ##

Now you've actually done something.  Which means there's two concurrent 
threads hitting the same site.

I've written badly unthreadsafe MySQL code before, and it gives me wonky 
results but not a crash like you describe.  That's ugly.  But I assume 
it's some sort of threadsafety issue.

Have you tried turning debugging on in the connection (add debug=1 to 
your connection constructor)?  Whatever comes before the fall?  Each 
line starts with a connection ID, which should be useful.  Adding the 
thread name to DBConnection.printDebug would also probably be useful, like:

     def printDebug(self, conn, s, name, type='query'):
         if type == 'query':
             sep = ': '
         else:
             sep = '->'
             s = repr(s)
         n = self._connectionNumbers[id(conn)]
         spaces = ' '*(8-len(name))
         threadName = threading.currentThread().getName()
         print ('%(n)2i:%(threadName)s/%(name)s%(spaces)s%(sep)s %(s)s' %
                locals())

   Ian

Re: [SQLObject] select() causes SQLObject + webware application to die

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

At LoppEar's suggestion in #webware, I've made a crude threaded app to
test with - it also dies, mysteriously printing "Killed" and dropping
back to the command prompt.  Any idea where this comes from?  Can anyone
else reproduce?

### Start Test 4 #

def main(args):
    import thread
    for t in range(2):
        thread.start_new_thread(whackit, ())
    while -1:
        pass
    
def whackit():
    t = 0
    while t < 1000:
        t += 1
        peeps = Person.select(Person.q.email=='xxx')
        try:
            user = peeps[0]
        except:
            user = None
    print t

### End Test 4 #

Re: [SQLObject] select() causes SQLObject + webware application to die

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

Replying to myself here... Replacing the MySQL connection with a
postgres one doesn't fix anything - although it seems to last about
twice as long, maybe 6 seconds under constant hammering.

How would I even start debugging this?

On Tue, 2004-03-02 at 14:18, Scott Russell wrote:
> I've found a situation in which SQLobject makes webware fall over like a
> straw house...
> 
> First, a very simple webware servlet:
> 
> ### Start 1 ##
> from WebKit.Page import Page
> from SQLObject import *
> 
> __connection__ = MySQLConnection(host="host", 
>                                  user="user", 
>                                  passwd="passwd", 
>                                  db="db")
> 
> class Person(SQLObject):
>     email = StringCol(length=40, default=None)
>     firstname = StringCol(length=30, default=None)
>     lastname = StringCol(length=30, default=None)
> 
> class TestPage(Page):
>     def writeContent(self):
>         p = Person(1)        
>         self.writeln('''Welcome.''')
> ### End 1 ##
> 
> I hammer and hammer and hammer, and it holds up fine - as hard as I can
> hit it, it keeps up with me.
> 
> Now, a Second Servlet: (Only Changing the TestPage class - everything
> else is the same.)
> 
> ### Start 2 ##
> class TestPage(Page):
>     def writeContent(self):
>         peeps = Person.select(Person.q.email=='xxx')
>         self.writeln('''Welcome.''')
> ### End 2 ##
> 
> Once again, this holds up wonderfully.  It never fails, as far as I can
> tell.  Rock solid.
> 
> Now, for the bad one.  One more TestPage servlet, this time with an
> accessor for peeps.
> 
> ### Start 3 ##
> class TestPage(Page):
>     def writeContent(self):
>         peeps = Person.select(Person.q.email=='xxx')
>         p = peeps[0]
>         self.writeln('''Welcome''')
> ### End 3 ##
> 
> This one functions fine, and seems to work fine until the hammering
> begins, in which case it is guaranteed to fall over within 3 seconds,
> repeatably, every time.  If used at a reasonable pace, it still falls
> over, eventually.  Similar tests have found select() to be the culprit -
> th emore you use it, the faster death occurs.  The strangest issue?  How
> it dies - I've modified Webkit to print it's exit code.  Normally, it's
> 3, and that tells webkit's shell script to restart it.  When it falls
> over here, it receives a 137 - which is a "kill -KILL" signal, if I'm
> correct...
> 
> Can someone explain this, and hopefully show what I'm doing wrong?  I'm
> actually supposed to be deploying a site reasonably soon, and can't in
> it's current state - two users kill it in just over a minute.  I'll be
> in #webware on irc.freenode.net if anyone wants to compare notes.
> 
>   - Scott
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

[SQLObject] Form fields and SQLObject

[<mar...@ge...>]

I am new to Python and SQLObject and I am looking for tips on how to do a search in a web application that uses SQLObject.

For testing/learning purposes I am using the Person class from the SQlObject:
	
from SQLObject import *

class Person(SQLObject):
	_connection = MySQLConnection(host='localhost', db='test', user='*', passwd='*', debug=1)
	
	firstName = StringCol(length=100)
	middleInitial = StringCol(length=1, default=None)
	lastName = StringCol(length=100)

So far I have a findPerson method that looks like this:

def findPerson(self, id, fn, mi, ln):
	persons = Person.select(
						AND(Person.q.firstName.startswith(fn),
							Person.q.middleInitial.startswith(mi),
							Person.q.lastName.startswith(ln)))
	return persons

Where id, fn, mi and ln are the values of the fields in my search form - not very impressive and problematic in many ways I know !

What I would like is to implement a findPerson method that, based on the field values incl. any operators - *, <, >, <=, >= and so on, is able to perform a proper search and return all matching Person objects(rows). I have fiddled around with some inelegant string substitution to ugly to post. Especially properties - in this case middleInitial - that defaults to None, are troublesome, since an empty field is not matched by None.

Is there a elegant preferably generic solution for the above ? by generic I mean somthing that would work irrespective of the specific class.

I am using Python 2.3 on Windows 2000 and SQLObject 0.5.1.

Ian Bicking - super cool tool.

Regards,

Martin

-------------------------------------------------
WebMail fra Tele2 http://www.tele2.dk
-------------------------------------------------

[SQLObject] select() causes SQLObject + webware application to die

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

I've found a situation in which SQLobject makes webware fall over like a
straw house...

First, a very simple webware servlet:

### Start 1 ##
from WebKit.Page import Page
from SQLObject import *

__connection__ = MySQLConnection(host="host", 
                                 user="user", 
                                 passwd="passwd", 
                                 db="db")

class Person(SQLObject):
    email = StringCol(length=40, default=None)
    firstname = StringCol(length=30, default=None)
    lastname = StringCol(length=30, default=None)

class TestPage(Page):
    def writeContent(self):
        p = Person(1)        
        self.writeln('''Welcome.''')
### End 1 ##

I hammer and hammer and hammer, and it holds up fine - as hard as I can
hit it, it keeps up with me.

Now, a Second Servlet: (Only Changing the TestPage class - everything
else is the same.)

### Start 2 ##
class TestPage(Page):
    def writeContent(self):
        peeps = Person.select(Person.q.email=='xxx')
        self.writeln('''Welcome.''')
### End 2 ##

Once again, this holds up wonderfully.  It never fails, as far as I can
tell.  Rock solid.

Now, for the bad one.  One more TestPage servlet, this time with an
accessor for peeps.

### Start 3 ##
class TestPage(Page):
    def writeContent(self):
        peeps = Person.select(Person.q.email=='xxx')
        p = peeps[0]
        self.writeln('''Welcome''')
### End 3 ##

This one functions fine, and seems to work fine until the hammering
begins, in which case it is guaranteed to fall over within 3 seconds,
repeatably, every time.  If used at a reasonable pace, it still falls
over, eventually.  Similar tests have found select() to be the culprit -
th emore you use it, the faster death occurs.  The strangest issue?  How
it dies - I've modified Webkit to print it's exit code.  Normally, it's
3, and that tells webkit's shell script to restart it.  When it falls
over here, it receives a 137 - which is a "kill -KILL" signal, if I'm
correct...

Can someone explain this, and hopefully show what I'm doing wrong?  I'm
actually supposed to be deploying a site reasonably soon, and can't in
it's current state - two users kill it in just over a minute.  I'll be
in #webware on irc.freenode.net if anyone wants to compare notes.

  - Scott

Re: [SQLObject] StringCol() only saving 64k

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

On Tue, Mar 02, 2004 at 12:42:54AM -0600, Ian Bicking wrote:
> On Mar 1, 2004, at 8:05 AM, David McNab wrote:
> >I'm trying to save a fat wad of data in a StringCol column, but only 
> >the first 65536 chars are getting saved.
> >
> >Is this a MySQL restriction, or something in SQLObject?
> 
> That's a MySQL restriction (I'd guess -- certainly not SQLObject).  You 
> might have better luck with a BLOB column (as opposed to TEXT).

   Not neccessary. Just use MEDUIMTEXT, or LONGTEXT. Or MEDIUMBLOB or
LOBGBLOB.
   But always look into docs. That 65535 bytes is described there.

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

Re: [SQLObject] StringCol() only saving 64k

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

On Mar 1, 2004, at 8:05 AM, David McNab wrote:
> I'm trying to save a fat wad of data in a StringCol column, but only 
> the first 65536 chars are getting saved.
>
> Is this a MySQL restriction, or something in SQLObject?

That's a MySQL restriction (I'd guess -- certainly not SQLObject).  You 
might have better luck with a BLOB column (as opposed to TEXT).

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

[SQLObject] Re: StringCol() only saving 64k

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

"David McNab" <da...@re...> wrote in message
news:404...@re......
> I'm trying to save a fat wad of data in a StringCol column, but only the
> first 65536 chars are getting saved.
>
> Is this a MySQL restriction, or something in SQLObject?
>
> Either way, is there a way around this?

I think the best thing to do is NOT use the database to store chunks of data
that big. It can be pretty inefficient with a large table. Writing to the
file system is best.

This doesn't mean you have to stop using SQLObject though! :) SQLObject lets
you add your own functions that get called when a user tries to access an
SQLObject attribute (or any python object, for that matter...).

I think that's probably the best way to do it. Of course, I don't know what
you're trying to do... so take it with a grain of salt.

Here's how you use magic attributes:


http://sqlobject.org/docs/SQLObject.html#adding-magic-attributes-properties

Enjoy!

Re: [SQLObject] Finding StringCol lengths

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

jws...@ra... wrote:
> To create a basic gui form interface to my objects, I need to be able to get
> some sort of hints regarding the name, number and size of fields the object
> has. I can get a list of columns with _SO_Columns or _SO_columnDict, but
> that does not contain the field lengths I specified in my classes. My
> strategy was to create a public method that combined the private methods
> above and the length information from wherever I could find it. However, it
> seems that the length, if specified, is only used for validation and table
> creation. Where can I extract this information?

I believe you can get it through _SO_columnDict[colName].length, though 
only for StringCols, of course.  If you look in Col.SOString you'll see 
it being assigned.

   Ian