sqlobject-discuss — All things SQLObject-related

[SQLObject] StringCol() only saving 64k

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

Hi,

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?

-- 

Kind regards
David

--

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

[SQLObject] Finding StringCol lengths

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

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?

RE: [SQLObject] MultipleJoin does not respect specified keys

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

I apologize for not double checking that, the parameter is "joinColumn". It's
in the docs for MultipleJoin, been in code since the beginning as I recall.

- Luke

Quoting jws...@ra...:

> joinColumnName does not seem to exist. Is this only in cvs?
>
> -----Original Message-----
> From: Luke Opperman [mailto:lu...@me...]
> Sent: Sunday, February 29, 2004 3:27 AM
> To: Jeff Sacksteder
> Cc: sql...@li...
> Subject: Re: [SQLObject] MultipleJoin does not respect specified keys
>
>
>> It is apparently attempting to
>> guess what the primary key is based on the Style, even though I specified
>> the column name by hand. This is just a bit beyond my ability to fix at
> the
>> moment.
>
> Yes, it tries to guess based on style in this case. SQLObjects are still
> fairly
> self-contained, the CustAccount class does not search out the appropriate
> ForeignKey in ShipTo automatically to determine the name.
>
> You will want to change your join to specify the column name:
>
>  shiptos = MultipleJoin('Shipto', joinColumnName='cust_id')
>
> And that should take care of it.
>
> - Luke
>
>
> -------------------------------------------------------
> 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



--
The Pursuit of Counterfactual Histories

RE: [SQLObject] MultipleJoin does not respect specified keys

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

joinColumnName does not seem to exist. Is this only in cvs? 

-----Original Message-----
From: Luke Opperman [mailto:lu...@me...]
Sent: Sunday, February 29, 2004 3:27 AM
To: Jeff Sacksteder
Cc: sql...@li...
Subject: Re: [SQLObject] MultipleJoin does not respect specified keys


> It is apparently attempting to
> guess what the primary key is based on the Style, even though I specified
> the column name by hand. This is just a bit beyond my ability to fix at
the
> moment.

Yes, it tries to guess based on style in this case. SQLObjects are still
fairly
self-contained, the CustAccount class does not search out the appropriate
ForeignKey in ShipTo automatically to determine the name.

You will want to change your join to specify the column name:

  shiptos = MultipleJoin('Shipto', joinColumnName='cust_id')

And that should take care of it.

- Luke

Re: [SQLObject] MultipleJoin does not respect specified keys

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

> It is apparently attempting to
> guess what the primary key is based on the Style, even though I specified
> the column name by hand. This is just a bit beyond my ability to fix at the
> moment.

Yes, it tries to guess based on style in this case. SQLObjects are still fairly
self-contained, the CustAccount class does not search out the appropriate
ForeignKey in ShipTo automatically to determine the name.

You will want to change your join to specify the column name:

  shiptos = MultipleJoin('Shipto', joinColumnName='cust_id')

And that should take care of it.

- Luke

[SQLObject] MultipleJoin does not respect specified keys

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

Given the following classes, when I call 'shiptos' on an instance of my
CustAccount class, I see that the resulting SQL looks like 'SELECT shipto_id
FROM shiptos WHERE cust_accounts_id = 2'. It is apparently attempting to
guess what the primary key is based on the Style, even though I specified
the column name by hand. This is just a bit beyond my ability to fix at the
moment.

class CustAccount(SQLObject):
	_table = "cust_accounts"
	_idName = "cust_id"
	name = StringCol()
	shiptos = MultipleJoin('Shipto')

class Shipto(SQLObject):
	_table = "shiptos"
	_idName = "shipto_id"
	name = StringCol()
	cust = ForeignKey('CustAccount')

Re: [SQLObject] SQLObject vs mod_python security issue

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

On Feb 27, 2004, at 8:04 PM, David McNab wrote:
> In this scenario, with SQLObject table classes sitting in a 
> process-global registry, other users on the same server could get 
> access to my tables, which is not completely ideal.

Like other people said, I don't think you can get safety with 
mod_python in this situation.  And I don't think mod_python is much (if 
any) more common in vhosts than other Python environments.

> Is there any way to stop SQLObject from keeping this registry?

No, it's pretty essential -- the registry is how SQLObject finds other 
classes by name (for joins and foreign keys).  But if you are just 
worried about name conflicts, not malicious access, you can define a 
separate registry for your application by adding a _registry class 
variable to your classes (a string which identifies your application).

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

Re: [SQLObject] SQLObject vs mod_python security issue

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

> In this scenario, with SQLObject table classes sitting in a
> process-global registry, other users on the same server could get access
> to my tables, which is not completely ideal.

To agree with others posting on this issue, I don't see this as an SQLObject
issue, but rather the basic inappropriateness of a shared mod_python hosting
environment in general. Any environment in which you are sharing an instance
of the python interpreter with untrusted parties is simply not going to be
secure. A module-level registry makes this apparent, but getting rid of global
stores does not change the openness of a python interpreter instance. The
rexec/Bastion issues immediately spring to mind as an illustration.

- Luke

Re: [SQLObject] SQLObject vs mod_python security issue

[Bob I. <bo...@re...>]

On Feb 27, 2004, at 9:49 PM, David McNab wrote:

> Michael Watkins wrote:
>> BTW I use Quixote and that project's "SCGI" to avoid one-shot CGI. 
>> SCGI
>> uses mod_scgi to simply pass http requests off to the long-running 
>> scgi
>> process (which is a Publisher subclass which your application creates)
>> for the application. There certainly is no shared space between
>> individual applications or users - so might be handy in a vhosts
>> situation.
>
> Except that less than 2% of vhosts allow persistent processes.
>
> (Not many allow mod_python either, but I'd suspect that there's more 
> vhosts allowing mod_python than persistent processes).

mod_python is just simply not appropriate for those kinds of vhost 
environments.  I certainly wouldn't put anything I care about in a 
shared python interpreter with people I don't trust, nor would I use an 
ISP that was foolish enough to offer that without the option of 
persistent processes.  I do understand that some people can't afford 
decent hosting for whatever reason, and they should just learn PHP ;)

Besides, I bet persistent processes have better performance and 
scalability.. most requests probably aren't hitting mod_python, so 
you're eating up more memory than you need.. and if they are mostly 
hitting python scripts, then what the heck are you using apache for in 
the first place?  It (apache+mod_python) doesn't make anything easier 
or more reliable.

-bob

Re: [SQLObject] SQLObject vs mod_python security issue

[Michael W. <mw...@mi...>]

On Sat, 2004-02-28 at 07:49, David McNab wrote:
> Except that less than 2% of vhosts allow persistent processes.
> 
> (Not many allow mod_python either, but I'd suspect that there's more 
> vhosts allowing mod_python than persistent processes).

Yup, that is indeed an issue. I ended up building out my own rack
mounted servers and shipped them off to a co-location centre. Obviously
not practical for some...

Its probably worth checking into what vhost'ers will and will not do
these days. Perhaps they are looking for business with more vigor than
in the hey day of 1999/2000 ;-)

Also I suspect you would find a friendly ear at any site that supports
Zope, since its running a persistent process - and there are quite a few
Zope hosters out there these days. SCGI/Quixote with Apache is far, far,
lighter load on a server than Zope. Even if you write an application
badly (I'm guilty of that I am sure)!

In support of SCGI, a typical application starts up only a couple SCGI
processes - doesn't matter if you have 10 or 50 apache processes, unless
your application is extremely heavily used, those two SCGI processes
will keep up just fine. So the load potentially might be lighter
(resource wise at lease) than some Apache/mod_python configurations.

Mike

Re: [SQLObject] SQLObject vs mod_python security issue

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

Michael Watkins wrote:
> BTW I use Quixote and that project's "SCGI" to avoid one-shot CGI. SCGI
> uses mod_scgi to simply pass http requests off to the long-running scgi
> process (which is a Publisher subclass which your application creates)
> for the application. There certainly is no shared space between
> individual applications or users - so might be handy in a vhosts
> situation. 

Except that less than 2% of vhosts allow persistent processes.

(Not many allow mod_python either, but I'd suspect that there's more 
vhosts allowing mod_python than persistent processes).

David

Re: [SQLObject] SQLObject vs mod_python security issue

[Michael W. <mw...@mi...>]

On Sat, 2004-02-28 at 07:04, David McNab wrote:
> I've just noticed that SQLObject keeps some sort of process-global 
> 'registry' of tables.
> 
> This creates a security situation with mod_python.

Interesting. I've never used mod_python and it never occured to me to
think about this. Thanks for the heads up.

BTW I use Quixote and that project's "SCGI" to avoid one-shot CGI. SCGI
uses mod_scgi to simply pass http requests off to the long-running scgi
process (which is a Publisher subclass which your application creates)
for the application. There certainly is no shared space between
individual applications or users - so might be handy in a vhosts
situation. 

I run my own web servers and have client implementations each running
their python applications with no concerns. And it performs very well
too.

But then I happen to like the Quixote model, ymmv...



--
Mike Watkins
mw...@mi...


Absence makes the heart go wander.

[SQLObject] SQLObject vs mod_python security issue

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

Hi,

I've just noticed that SQLObject keeps some sort of process-global 
'registry' of tables.

This creates a security situation with mod_python.

At present, I'm using SQLObject within mod_python on my own server. No 
problem here, because I can either just:
1) create my tables once within my mod_python handler, or
2) create the tables upon each hit, trapping the resulting exceptions on 
the second/subsequent hits.

However, I'm looking to possibly move one or more sites to a shared 
vhost server.

In this scenario, with SQLObject table classes sitting in a 
process-global registry, other users on the same server could get access 
to my tables, which is not completely ideal.

Is there any way to stop SQLObject from keeping this registry?

Or, should I only host mod_python/SQLObject-using websites on hosts that 
have separate users running within separate Apache processes?

-- 

Kind regards
David

--

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

Re: [SQLObject] Overloading related joins and multiple joins

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

Victor Ng wrote:
> If I have two classes like this:
> 
> class Foo(SQLObject):
>     bars = RelatedJoin('Bar')
> 
> class Bar(SQLObject):
>     foos = RelatedJoin('Foo')
> 
> Is there a way for me to overload the addFoo and addBar method for Bar 
> and Foo?

Only by brute force:

class Foo(SQLObject):
     bars = RelatedJoin('Bar')

oldAddBar = Foo.addBar
def newAddBar(self):
     result = oldAddBar(self)
     yada yada
Foo.addBar = newAddBar


Cheers,
   Ian

[SQLObject] Overloading related joins and multiple joins

[Victor Ng <vn...@sy...>]

If I have two classes like this:

class Foo(SQLObject):
	bars = RelatedJoin('Bar')

class Bar(SQLObject):
	foos = RelatedJoin('Foo')

Is there a way for me to overload the addFoo and addBar method for Bar 
and Foo?

vic

[SQLObject] Re: defining 1 to many relationships

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

>The images table contains a field called source_di which links to the di id
field which is also the key for the di table. i defined the table classes
like this:
>
> class Images(SQLObject):
>     _idName = 'uin'
>     _fromDatabase  = True
>     sourceDi = ForeignKey('Di')
>
> class Di(SQLObject):
>     _fromDatabase = True
>     _idName = 'id'
>     Images = ForeignKey('Images')

The problem is that a ForeignKey column gives you back one object, since
it's for references to a single index in another table. So, when you access
Images in Di, it ain't gunna work.

You have to make Images = MultipleJoin('Images'). You may also have to go
into SQL and rename the column in the Images table that references back to
Di, although I'm not certain about this. I am a bit new to SQLObject myself.
:)

= Chris Gahan =============
  (ch...@il...)

[SQLObject] defining 1 to many relationships

[<jo...@cy...>]

Dear Group,

i just started looking at SQLObject and i ahve a question.  I am trying to see if it will work with a database that I already have developed with data in MySQL.  I have two tables images and di (donating investigator) and there is a 1 to many relationship between di and images.  The images table contains a field called source_di which links to the di id field which is also the key for the di table. i defined the table classes like this:

class Images(SQLObject):
    _idName = 'uin'
    _fromDatabase  = True
    sourceDi = ForeignKey('Di')

class Di(SQLObject):
    _fromDatabase = True
    _idName = 'id'
    Images = ForeignKey('Images')


When I try and run

images = Images.select()
for i in images:
    print i.uin

but this does not work, and the error message says that there is no column called imags.source_di_id

am I out of luck unless I want to redesign the database?

Thanks for any and all help

Jose

[SQLObject] [PATCH] missing return

[Sidnei da S. <si...@aw...>]

Howdy,

Seems like some 'return's are missing on __init__.py. Patch attached.

[]'s 
-- 
Sidnei da Silva <si...@aw...>
http://awkly.org - dreamcatching :: making your dreams come true
http://plone.org/about/team#dreamcatcher

If a train station is a place where a train stops, what's a workstation?

Re: [SQLObject] many destroySelf calls from w/in txn?

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

On Feb 23, 2004, at 1:33 AM, Joel Boehland wrote:
> I've just started playing around with SQLObject and have a question 
> about
> the use of SQLObject.destroySelf. It doesn't take a 
> connection/transaction
> as a parameter, so I can't see how to make it do multiple 
> destroySelf's from
> within a transaction. (i.e. destroy a list of User objects all in the 
> same transaction)
> Am I missing something, or is this something that needs to be added?

An object is already associated with a transaction at that point -- 
when you pass the transaction into the constructor (or .select or 
whatever), you get an object that is bound to that transaction, so when 
you delete it you delete it inside the transaction.

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

[SQLObject] many destroySelf calls from w/in txn?

[Joel B. <jo...@me...>]

Hi,
I've just started playing around with SQLObject and have a question about
the use of SQLObject.destroySelf. It doesn't take a connection/transaction
as a parameter, so I can't see how to make it do multiple destroySelf's from
within a transaction. (i.e. destroy a list of User objects all in the same transaction)
Am I missing something, or is this something that needs to be added?

--Joel

Re: [SQLObject] Bad connection timeout behaviour...

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

Hallo,
Chris Gahan hat gesagt: // Chris Gahan wrote:

> 
> What's the deal with the connection timeout behaviour?
> 
> I imported an SQLObject I created called Users, selected a couple items from
> it, then went away for a while. When I came back and selected another item
> from it, it threw an exception saying that the connection had timed out. It
> didn't try to reconnect, as you'd expect, but just died.
> 
> Then I did another query right afterwards, and it reconnected to the
> database and worked fine! This isn't very nice. It should really throw an
> exception if it CAN'T reconnect, not if it HAS to reconnect.

I faced the same error a lot some time ago. I don't think, it's the
fault of SQLObject, but more a bug somewhere in the mysql module or
even in mysql. The only workaround I found is a bit drastic: I now use
PostgreSQL, which solved all my problems.

ciao
-- 
 Frank Barknecht                               _ ______footils.org__

Re: [SQLObject] proxy attributes

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

On Feb 19, 2004, at 10:33 PM, jws...@ra... wrote:
> If I do a dir() on an instance of my class, I get a list of ALL private
> and public attributes. What is the best way for a program containing my
> SQLOject to get a list of the public attributes that object exposed in
> it's definition, excluding private and inherited items? The printable
> representation of the object looks like
>
> 	<Customer 6 name='ACME' buyerID=1>
>
> '_columns' lists the real columns, but not the proxied ones. I could 
> also
> just add a method in my class to return a list of fields. I'm thinking
> of generating a gui form based on what the object tells me it's fields 
> are.

Well, AFAIK there's not really a good way to list all the attributes of 
a class in a general sense.  Even hasattr (I believe) just tries to get 
the attribute, and if it gets an AttributeError it returns false -- 
there's no backdoor introspection that gives you everything.  It can be 
a little frustrating sometimes.

I'd advise that you think about this in more explicit terms -- you 
aren't exposing all attributes, you really want to expose specific 
attributes.

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

Re: [SQLObject] Dealing With PostgreSQL Constraints

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

CLIFFORD ILKAY wrote:
> How does SQLObject deal with constraint violations? Does it intercept 
> the error and present some meaningful interface via Python?

No, it just passes the errors through.

   Ian

Re: [SQLObject] Inserting Into Views With PostgreSQL

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

CLIFFORD ILKAY wrote:
> I really like the way that Oracle treats views as if they were virtual 
> tables and will allow one to do INSERT, UPDATE, and DELETE operations on 
> them and I equally dislike the way that PostgreSQL deals with views. It 
> is NOT straightforward at all. Is there some way using SQLObject that we 
> can abstract out the awkwardness of views in PostgreSQL. For example, 
> say we have a classic master/detail relationship, invoice headers and 
> invoice details. In Oracle, I would create a view called invoices and 
> simply treat it as if it were a table. Can I do something like the 
> following in SQLObject?
> 
> class(Invoice):
>         <define "view" like structure here>
> 
> inv = Invoice.new(bla, bla, bla)
> 
> Some of these views can abstract a fairly complex relationship 
> consisting of many tables being joined. It is much nicer having to deal 
> with the abstraction than having to deal with the underlying tables.

Daniel's inheritance patch might help you here.  The inheritance 
structure he uses is similar to the item/detail relationship you're 
talking about.

   Ian

Re: [SQLObject] How to insert a boolean into PostgreSQL

[CLIFFORD I. <cli...@di...>]

At 01:57 20/02/2004 -0600, Ian Bicking wrote:
>On Feb 20, 2004, at 1:29 AM, CLIFFORD ILKAY wrote:
>>I was able to create a PostgreSQL table with a boolean column by doing 
>>myClass.createTable but I cannot insert into it without SQLObject raising 
>>the following error:
>>
>>ValueError: Unknown SQL builtin type: <type 'instance'> for TRUE
>
>Hmm... are you using an early version of Python 2.2?  I think there was a 
>problem related to that version (before True and False were defined)

I am using Python 2.2.2 on Mandrake 9.1. This is the latest one for 9.1. I 
also have 2.3.3 installed from tarball but it is pretty devoid of 
site-packages so I have to install psycopg, etc.

>>I am attempting to insert as follows:
>>
>>p = person.new(firstName="Donald", lastName="Duck" , amtPaid="10.26", 
>>isParticipant=True)
>>
>>I tried assigning "", "T", 1 to isParticipant but all behaved the same 
>>way. NULLs are allowed for the boolean column. How can I insert into this 
>>table?
>>
>>Also, how would I specify a default value for a boolean column? I tried:
>>
>>isParticipant=BoolCol(default=True)
>>
>>and when I created the table, there was no default for the column.
>
>The default only applies to the object, not the table.  When you add a row 
>through SQLObject the default is used.

That makes it of limited use as I would like the DBMS to enforce these 
sorts of things.

Regards,

Clifford Ilkay
Dinamis Corporation
3266 Yonge Street, Suite 1419
Toronto, Ontario
Canada M4N 3P6

Tel: 416-410-3326