sqlobject-discuss — All things SQLObject-related

Re: [SQLObject] Join tables

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

On Nov 10, 2003, at 3:02 PM, John Baker wrote:
> On Monday 10 November 2003 20:56, Ian Bicking wrote:
>
>> doesn't involve terms (or even concepts) like "implicit" or "folding",
>> then maybe I'll feel more enthusiastic.  I'm trying to avoid magic to
>> the degree possible, which is where my reluctance comes from.
>
> I didn't really find a real reason in there ;-)
>
> Superset mapping makes obvious logical sense when you present the 
> model to an
> OO programmer. If you are talking objects, you map with supersets. 
> Some of my
> code to cope with the above example is absolutely sick, but I have no 
> choice.
> However SQLObject is free, so I'm not going to worry too much - I'll 
> just
> implement it for you one day :-)

Sure.  But I'm more likely to commit it if it fits my sensibilities ;)  
But who knows, it all depends on what the implementation looks like.  
Actually, the description of the implementation will be of the greatest 
interest to me.  If you can concisely, unambiguously, and completely 
describe how to use it, including all the corner cases and likely 
gotchas, then I'll be convinced.  (Keeping in mind that for SQLObject a 
description of use has to include the Python interface, the SQL schema 
required, and the queries produced; and, as a tool, extension and 
customization have to be accounted for)  If the implementation is a 
mess, that can be fixed -- if the semantics are a mess you're stuck.

> Consider other cases where you have a collection of objects that you 
> want to
> map back to one parent, regardless if  you are actually mapping to a 
> child.
> You might have a "Property", and you might want any object to have a
> collection of Properties. In OO, you'd define something like:
>
> class Item (SQLObject):
> 	properties = MultipleJoin("Property")
> 	name = StringCol()
>
> class Bill (Item):
> 	value = FloatCol()
>
> .. and many other extension of Item
>
> and every extension has access to the list of Properties.

And this is just what makes me nervous.  What does the Item table look 
like?  How does it relate to the rest of the system, and how does it 
grow?  Presumably Bill and other classes are keyed off of item_id, but 
how do you know which kind of Item you are working with?

Superclasses shouldn't have to be aware of subclasses, but I don't see 
how that can happen with this system.  Also, you get all sorts of 
weirdness in class creation -- essentially Item.__new__ will have to 
return a Bill instance, or some other instance, depending on the ID.

What looks like inheritance isn't really inheritance, it's something 
else.  I don't know what to call it, but I don't want to create a false 
cognate by phrasing it incorrectly -- especially when its in relation 
to something with the complex semantics of a Python class.

> We define OO structures to reduce our code and reuse objects, and 
> mappings to
> tables should work in exactly the same way. After all, why should the 
> OO
> developer have to worry about tables? The OO developer wants to store
> something, he/she doesn't want to worry about how it's stored...

I can appreciate this sentiment, but I'm also wary of it.  There are 
other Python ORMs that do better at distinguishing between business 
logic and persistence logic, but SQLObject is coming from a bit 
different perspective -- it's mapping tables to Python objects, not 
mapping Python classes to tables.  Ultimately I am unconvinced that you 
can get the persistence for free, that you can map arbitrary Python 
onto a DBMS -- at least without making the DBMS pointless.  Now, that's 
not to say SQLObject won't move more towards being a "seamless" 
persistency for objects; I have several ideas that could help improve 
this.  But I don't even know what "seamless" really means in this 
context -- no seamless persistence *can* exist in Python, because the 
status-quo is non-persistence (which will continue to be a viable 
option for a large number of objects and situations).

But I'm wandering off onto tangents.

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

Re: [SQLObject] Join tables

[John B. <jb...@dr...>]

On Monday 10 November 2003 21:41, Luke Opperman wrote:
> I'm a little unclear whether by superset mappings you are referring to
> Python class inheritance, or a more generic concept that happens to often

It's a more generic terminology.

> be modelled by OO inheritance. Part of the question, we've looked briefly
> at various ways of modeling inheritance, and currently take the approach of
> "one table for every concrete class, no shared attributes". This does
> ignore the possibly handy person.areas example you give, but doesn't have
> to make any guesses about what the coder meant by OO inheritance.
>
> What does person.areas return? Areas, or Homes and Offices? (just curious
> to make sure I'm understanding your example correctly.)

Actual concrete objects. So, you can either do SELECT's across all tables that 
extend Area to find the objects, or you can be more clever:

person.getAreas("Home")

to tell SQLObject that although the collection can contain any type of Area, 
you know (in this case), you've stored Home objects. Or you may just wish to 
get the Home objects. :)

> That's my key reason for agreeing with this current approach: Python (and
> most other OO languages) don't make a distinction between the various uses
> for inheritance, so let's not make a guess. :) So then, do we 'extend'
> python syntax to say "Home.subsetOf(Area)" and say that we always map that
> as your foreignKey representation? Doesn't sound half-bad to me, but there
> are alternate ways to represent it, and gets back to the
> magic-representation guessing I'd rather avoid.

But without it you get inefficent mappings, as I've highlighted.

If I had large structures, such as:

Item
   (has unique id, primary key, which we refer to for tedious reasons within 
the code, say for storing unique files associated with each Item)

Channel extends Item
   (has unique field specifying a channel id)
Periodic extends Channel
NonPeriodic extends Channel

Meter extends Item
Meter --* Channel

Location extends Item
  (location has a unique field, say a postcode/zipcode)
Site extends Location
House extends Location

SiteGroup *--* Location

Location --* Meter

You can see that flat tables just won't work nicely. How do you express a 
unique key for both Periodic and NonPeriodic channels? 

The inheritence is of vital importance in some designs. 'Superset' mapping 
isn't always the answer, as it can be inefficient, but once you get past 
noddy examples it's absolutely obvious.

There's a nice write up of mapping techniques here:

http://www.objectmatter.com/vbsf/docs/maptool/ormapping.html



John

-- 
John Baker,
(m) 07736393822
http://rant.pointful.info

Re: [SQLObject] Join tables

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

I'm a little unclear whether by superset mappings you are referring to Python
class inheritance, or a more generic concept that happens to often be modelled
by OO inheritance. Part of the question, we've looked briefly at various ways
of modeling inheritance, and currently take the approach of "one table for
every concrete class, no shared attributes". This does ignore the possibly
handy person.areas example you give, but doesn't have to make any guesses
about what the coder meant by OO inheritance.

What does person.areas return? Areas, or Homes and Offices? (just curious to
make sure I'm understanding your example correctly.)

That's my key reason for agreeing with this current approach: Python (and most
other OO languages) don't make a distinction between the various uses for
inheritance, so let's not make a guess. :) So then, do we 'extend' python
syntax to say "Home.subsetOf(Area)" and say that we always map that as your
foreignKey representation? Doesn't sound half-bad to me, but there are
alternate ways to represent it, and gets back to the magic-representation
guessing I'd rather avoid.

- Luke


Quoting John Baker <jb...@dr...>:

> On Monday 10 November 2003 20:36, Ian Bicking wrote:
> > On Nov 10, 2003, at 1:16 PM, John Baker wrote:
> > > We really need to discuss superset mappings at some point too ;-)
> >
> > What're those?
>
> class Area (SQLObject):
>
> class Office (Area):
>
> class Home (Area):
>
> SQLObject creates three tables, with a foreign key from Home -> Area and
> Office -> Area.
>
> This means I can do:
>
> class Person (SQLObject):
>   areas = ReferenceJoin("Area"...)
>
> and map a Person to a number of Areas, without having to map him to Office
> and
> Home via two join tables.
>
> Someone said superset mapping wouldn't be happening, which is a shame, as
> it's
> the most obvious and logical choice of the majority of OO mapping.
>
>
> John
>

Re: [SQLObject] Join tables

[John B. <jb...@dr...>]

On Monday 10 November 2003 20:56, Ian Bicking wrote:

> doesn't involve terms (or even concepts) like "implicit" or "folding",
> then maybe I'll feel more enthusiastic.  I'm trying to avoid magic to
> the degree possible, which is where my reluctance comes from.

I didn't really find a real reason in there ;-)

Superset mapping makes obvious logical sense when you present the model to an 
OO programmer. If you are talking objects, you map with supersets. Some of my 
code to cope with the above example is absolutely sick, but I have no choice. 
However SQLObject is free, so I'm not going to worry too much - I'll just 
implement it for you one day :-)

Consider other cases where you have a collection of objects that you want to 
map back to one parent, regardless if  you are actually mapping to a child. 
You might have a "Property", and you might want any object to have a 
collection of Properties. In OO, you'd define something like:

class Item (SQLObject):
	properties = MultipleJoin("Property")
	name = StringCol()

class Bill (Item):
	value = FloatCol()

.. and many other extension of Item

and every extension has access to the list of Properties.

We define OO structures to reduce our code and reuse objects, and mappings to 
tables should work in exactly the same way. After all, why should the OO 
developer have to worry about tables? The OO developer wants to store 
something, he/she doesn't want to worry about how it's stored...

I'll get on with my work now :)


John

-- 
John Baker,
(m) 07736393822
http://rant.pointful.info

Re: [SQLObject] Join tables

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

On Nov 10, 2003, at 2:42 PM, John Baker wrote:
> class Area (SQLObject):
>
> class Office (Area):
>
> class Home (Area):
>
> SQLObject creates three tables, with a foreign key from Home -> Area=20=

> and
> Office -> Area.
>
> This means I can do:
>
> class Person (SQLObject):
>   areas =3D ReferenceJoin("Area"...)
>
> and map a Person to a number of Areas, without having to map him to=20
> Office and
> Home via two join tables.
>
> Someone said superset mapping wouldn't be happening, which is a shame,=20=

> as it's
> the most obvious and logical choice of the majority of OO mapping.

That was probably me.  I find it difficult to map between class=20
hierarchies and tables, and I don't like the ambiguity or arbitrariness=20=

of how that mapping has to happen.
=1F
Which isn't to say I'd be opposed to superset mapping, I'd just rather=20=

that it not look like Python inheritance.  To me it's more of an=20
implicit join.  Or the folding together of multiple tables.  Or... I=20
don't know.  When I see a metaphor that looks better, and hopefully=20
doesn't involve terms (or even concepts) like "implicit" or "folding",=20=

then maybe I'll feel more enthusiastic.  I'm trying to avoid magic to=20
the degree possible, which is where my reluctance comes from.

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

Re: [SQLObject] Join tables

[John B. <jb...@dr...>]

On Monday 10 November 2003 20:36, Ian Bicking wrote:
> On Nov 10, 2003, at 1:16 PM, John Baker wrote:
> > We really need to discuss superset mappings at some point too ;-)
>
> What're those?

class Area (SQLObject):

class Office (Area):

class Home (Area):

SQLObject creates three tables, with a foreign key from Home -> Area and 
Office -> Area.

This means I can do:

class Person (SQLObject):
  areas = ReferenceJoin("Area"...)

and map a Person to a number of Areas, without having to map him to Office and 
Home via two join tables. 

Someone said superset mapping wouldn't be happening, which is a shame, as it's 
the most obvious and logical choice of the majority of OO mapping.


John

-- 
John Baker,
(m) 07736393822
http://rant.pointful.info

Re: [SQLObject] Join tables

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

On Nov 10, 2003, at 1:12 PM, Sidnei da Silva wrote:
> On Mon, Nov 10, 2003 at 06:20:47PM +0000, John Baker wrote:
> | And back to deleting objects. If A has many Bs, there should be a 
> way of
> | declaring it an 'owned relationship', in terms of 'when I delete A, 
> all my Bs
> | are deleted'.
> |
> | Perhaps a flag on MultipleJoin. destroyChildrenWhenDestroyed=True
>
> Like a cascade delete?
>
> BTW, I wanted to know if there is cascade delete support on
> SQLObject. I'm going to need it RSN :)

No, no support.  Right now you can do it manually by overriding 
destroySelf, e.g.:

class Story(SQLObject):
     def destroySelf(self):
         for reply in self.replies:
             reply.destroySelf()
         super(Story, self).destroySelf()

Certainly it could be added without great difficulty... a number of 
things need to happen with joins (like one-to-one joins need to be 
written, and a clearly documented many-to-many-with-extra-info join, 
like employee to client + rate).  Then there's the possibility of 
making joins smarter, like SelectResults, so that you'd do things like 
employee.clients.append(aClient).

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

Re: [SQLObject] Join tables

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

On Nov 10, 2003, at 1:16 PM, John Baker wrote:
> We really need to discuss superset mappings at some point too ;-)

What're those?

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

Re: [SQLObject] Join tables

[John B. <jb...@dr...>]

On Monday 10 November 2003 19:12, Sidnei da Silva wrote:
> On Mon, Nov 10, 2003 at 06:20:47PM +0000, John Baker wrote:
> | And back to deleting objects. If A has many Bs, there should be a way of
> | declaring it an 'owned relationship', in terms of 'when I delete A, all
> | my Bs are deleted'.
> |
> | Perhaps a flag on MultipleJoin. destroyChildrenWhenDestroyed=True
>
> Like a cascade delete?
>
> BTW, I wanted to know if there is cascade delete support on
> SQLObject. I'm going to need it RSN :)

Yes!

Having come from www.objectmatter.com, and spent  plenty of time helping them 
develop that, I feel like I've gone back in time :)

We really need to discuss superset mappings at some point too ;-)

-- 
John Baker,
(m) 07736393822
http://rant.pointful.info

Re: [SQLObject] Join tables

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

On Mon, Nov 10, 2003 at 06:20:47PM +0000, John Baker wrote:
| And back to deleting objects. If A has many Bs, there should be a way of 
| declaring it an 'owned relationship', in terms of 'when I delete A, all my Bs 
| are deleted'.
| 
| Perhaps a flag on MultipleJoin. destroyChildrenWhenDestroyed=True 

Like a cascade delete? 

BTW, I wanted to know if there is cascade delete support on
SQLObject. I'm going to need it RSN :)

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

This screen intentionally left blank.

Re: [SQLObject] Join tables

[John B. <jb...@dr...>]

And back to deleting objects. If A has many Bs, there should be a way of 
declaring it an 'owned relationship', in terms of 'when I delete A, all my Bs 
are deleted'.

Perhaps a flag on MultipleJoin. destroyChildrenWhenDestroyed=True 


john

On Monday 10 November 2003 16:05, you wrote:
> On Nov 10, 2003, at 2:02 AM, John Baker wrote:
> > On Monday 10 November 2003 00:57, Ian Bicking wrote:
> >>  From a quick inspection of the code, no, that's not implemented.
> >> Yes,
> >> it should be.
> >
> > Goodo. Will it appear in the next version? Should only be a few lines
> > I'd
> > guess?
>
> Yes, it should probably go into the next version.
>
> >> Hmm... right now if, say, you have a many-to-one relationship between
> >> Replies and Stories, then you have Story.replies.  But that's just a
> >> dumb list.  I've thought about an addReply-like method, which would
> >> assign the story_id column of Reply.  But I don't quite like it,
> >> because you aren't just adding the reply, you are moving it (if it
> >> previously had a story).
> >
> > Yes, that's right, and consistent. It seems rather odd assigning Reply
> > to a
> > Story through the new method on Reply ...
> >
> > Reply.new(... story = s)
> >
> > That's odder :)
> >
> > If you think in terms of OO and you're used to Collections, you think
> > about
> > adding something to a Collection.
>
> No, it's quite different from a normal collection.  Normal collections
> -- in Python and most other languages -- are many-to-many, i.e., an
> object can be part of multiple collections.  One-to-many relations
> typically imply something more like ownership.
>
> It might be reasonable to "add" a reply to a story if the reply's story
> is already None, but in the more general sense the reply is being
> "moved", not "added".
>
> --
> Ian Bicking | ia...@co... | http://blog.ianbicking.org

-- 
John Baker,
(m) 07736393822
http://rant.pointful.info

Re: [SQLObject] Join tables

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

On Nov 10, 2003, at 2:02 AM, John Baker wrote:
> On Monday 10 November 2003 00:57, Ian Bicking wrote:
>>  From a quick inspection of the code, no, that's not implemented.  
>> Yes,
>> it should be.
>
> Goodo. Will it appear in the next version? Should only be a few lines 
> I'd
> guess?

Yes, it should probably go into the next version.

>> Hmm... right now if, say, you have a many-to-one relationship between
>> Replies and Stories, then you have Story.replies.  But that's just a
>> dumb list.  I've thought about an addReply-like method, which would
>> assign the story_id column of Reply.  But I don't quite like it,
>> because you aren't just adding the reply, you are moving it (if it
>> previously had a story).
>
> Yes, that's right, and consistent. It seems rather odd assigning Reply 
> to a
> Story through the new method on Reply ...
>
> Reply.new(... story = s)
>
> That's odder :)
>
> If you think in terms of OO and you're used to Collections, you think 
> about
> adding something to a Collection.

No, it's quite different from a normal collection.  Normal collections 
-- in Python and most other languages -- are many-to-many, i.e., an 
object can be part of multiple collections.  One-to-many relations 
typically imply something more like ownership.

It might be reasonable to "add" a reply to a story if the reply's story 
is already None, but in the more general sense the reply is being 
"moved", not "added".

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

Re: [SQLObject] Unicode support

[Guenther S. <gs...@sy...>]

On Sun, 2003-11-09 at 15:32, John Baker wrote:

Hello,

> Does SQLObject have any kind of Unicode support? We seem unable to find any, 
> and we've put a few hacks in there to encode Strings as utf-8 before they are 
> placed into the database, and decodes them after they come out. It's nothing 
> special, but I do feel SQLObject is lacking something here.

Which database would you like to use? I've posted a patch which includes
support for the PyPgSQL Postgres Adapter some time ago. Unlike other
Postgres Adapters, PyPgSQL supports Unicode.

I did some tests, and the patch seemed to work, but i haven't used it in
production yet.

cu
/gst

[SQLObject] Patch for class discovery from database for SQLite

[Peter W. <sou...@te...>]

Ian,
Here is a first go at a patch to allow SQLObject to build classes from 
SQLite databases. It uses a the same code as MySQLConnection with some 
very small changes, this means that to have this work the columns in 
SQLite tables have to have types set and use the type names that MySQL 
uses.

Where in the tests should I add a test for this?

Index: SQLObject/DBConnection.py
===================================================================
RCS file: /cvsroot/sqlobject/SQLObject/SQLObject/DBConnection.py,v
retrieving revision 1.54
diff -r1.54 DBConnection.py
747a748,781
 >     def columnsFromSchema(self, tableName, soClass):
 >         """
 >         Look at the given table and create Col instances (or
 >         subclasses of Col) for the fields it finds in that table.
 >         """
 >
 >         fieldqry = "PRAGMA table_info(%s)"
 >
 >         colData = self.queryAll(fieldqry % tableName.upper())
 >         results = []
 >         for pos, field, t, nullAllowed, thedefault in colData:
 >             if field == 'id':
 >                 continue
 >             colClass, kw = self.guessClass(t)
 >             kw['name'] = soClass._style.dbColumnToPythonAttr(field)
 >             kw['notNone'] = not nullAllowed
 >             kw['default'] = thedefault
 >             results.append(colClass(**kw))
 >         return results
 >
 >     def guessClass(self, t):
 >         if t.startswith('int'):
 >             return Col.IntCol, {}
 >         elif t.startswith('varchar'):
 >             return Col.StringCol, {}
 >         elif t.startswith('char'):
 >             return Col.StringCol, {}
 >         elif t.startswith('datetime'):
 >             return Col.DateTimeCol, {}
 >         elif t.startswith('bool'):
 >             return Col.BoolCol, {}
 >         else:
 >             return Col.Col, {}
 >


--
Regards,
Peter Wilkinson.

Re: [SQLObject] Join tables

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

On Nov 9, 2003, at 5:01 PM, John Baker wrote:
> If I have a join between A and B called AjoinB, and I remove A via
> A.destroySelf(); is SQLObject supposed to clean the join tables?
>
> If the answer is no, I suspect this would be a very handy feature...

 From a quick inspection of the code, no, that's not implemented.  Yes, 
it should be.

> Also, further to my previous mail about Story and Reply, where I could 
> not do
> Story.addReply (MultipleJoin), I think that's because I'm supposed to 
> pass
> the Story to the Reply as I build it. I think there should also be a 
> method
> of doing this via Story.addReply, where SQLObject 'commits' the 'new' 
> Reply
> to the database and sets up the foreign key pointing back to the 
> Story. That
> would be more consistent.

Hmm... right now if, say, you have a many-to-one relationship between 
Replies and Stories, then you have Story.replies.  But that's just a 
dumb list.  I've thought about an addReply-like method, which would 
assign the story_id column of Reply.  But I don't quite like it, 
because you aren't just adding the reply, you are moving it (if it 
previously had a story).

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

Re: [SQLObject] MultipleJoin confusion

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

Hallo,
John Baker hat gesagt: // John Baker wrote:

> class Story (SQLObject):
>   _connection = getConnection()
> 
>   storyId = StringCol()
>   authorContact = ForeignKey("Contact")
>   date = IntCol()
>   title = StringCol()
>   summary = StringCol()
>   body = StringCol()
>   replies = MultipleJoin('Reply')
> 
> 
> and
> 
> 
> class Reply (SQLObject):
>   _connection = getConnection()
> 
>   replyId = StringCol()
>   author = StringCol()
>   email = StringCol()
>   date = IntCol()
>   body = StringCol()
>   story = ForeignKey("Story")
> 
> 
> yet I can't call addReply to an instance of Story:
> 
>   File "./db.py", line 406, in buildDatabase
>     s.addReply(r)
> AttributeError: 'Story' object has no attribute 'addReply'
> 
> Any thoughts?

I didn't look it up, but it might be, that SQLObject has a problem
with the plurals in words ending in "y". What happens if you use, for
example, "comment" and "comments" here?

ciao
-- 
 Frank Barknecht                               _ ______footils.org__

[SQLObject] Join tables

[John B. <jb...@dr...>]

If I have a join between A and B called AjoinB, and I remove A via 
A.destroySelf(); is SQLObject supposed to clean the join tables?

If the answer is no, I suspect this would be a very handy feature...

Also, further to my previous mail about Story and Reply, where I could not do 
Story.addReply (MultipleJoin), I think that's because I'm supposed to pass 
the Story to the Reply as I build it. I think there should also be a method 
of doing this via Story.addReply, where SQLObject 'commits' the 'new' Reply 
to the database and sets up the foreign key pointing back to the Story. That 
would be more consistent.


John

-- 
John Baker,
(m) 07736393822
http://rant.pointful.info

Re: [Webware-discuss] Re: [SQLObject] 'Lost connection to MySQL server during query'

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

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

> On Nov 9, 2003, at 8:25 AM, Frank Barknecht wrote:
> >This happens with using python2.2 mysqldb 0.9.1 (the Debian package)
> >as well as with python2.3-mysqldb 0.9.2 and SQLObject CVS or 0.5. Did
> >anybody here run into something like this before and/or does someone
> >have an idea, what to do against this? If this happens, I get stale
> >Webware threads, which makes automatic restarting a bit of a hassle.
> 
> Could this be related to the problem people are discussing with 
> MiddleKit and MySQL on the Webware list?  I don't really have any 
> further thoughts, but maybe you should bounce this off them too.

Well, the problem discussed on webware-devel has two differences: the
error message is another one ("too many connections") and it seems to
only happen with mysqldb 0.9.2, whereas my problem also occurs on
0.9.1. Of course it might still be related. Searching the web, I found
two possible reasons. One is related to MySQL doing slow DNS lookups,
but that isn't the case on my machines: TCP connect to mysql is
disabled.

The other thing seems to be related to DB-connections not getting
closed or garbage-collected. But this is a quite bit over my Pythonic
head and my insight into SQLObject.

ciao
-- 
 Frank Barknecht                               _ ______footils.org__

[SQLObject] MultipleJoin confusion

[John B. <jb...@dr...>]

Hello,

I've got this:

class Story (SQLObject):
  _connection = getConnection()

  storyId = StringCol()
  authorContact = ForeignKey("Contact")
  date = IntCol()
  title = StringCol()
  summary = StringCol()
  body = StringCol()
  replies = MultipleJoin('Reply')


and


class Reply (SQLObject):
  _connection = getConnection()

  replyId = StringCol()
  author = StringCol()
  email = StringCol()
  date = IntCol()
  body = StringCol()
  story = ForeignKey("Story")


yet I can't call addReply to an instance of Story:

  File "./db.py", line 406, in buildDatabase
    s.addReply(r)
AttributeError: 'Story' object has no attribute 'addReply'

Any thoughts?


John

-- 
John Baker,
(m) 07736393822
http://rant.pointful.info

Re: [SQLObject] 'Lost connection to MySQL server during query'

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

On Nov 9, 2003, at 8:25 AM, Frank Barknecht wrote:
> This happens with using python2.2 mysqldb 0.9.1 (the Debian package)
> as well as with python2.3-mysqldb 0.9.2 and SQLObject CVS or 0.5. Did
> anybody here run into something like this before and/or does someone
> have an idea, what to do against this? If this happens, I get stale
> Webware threads, which makes automatic restarting a bit of a hassle.

Could this be related to the problem people are discussing with 
MiddleKit and MySQL on the Webware list?  I don't really have any 
further thoughts, but maybe you should bounce this off them too.

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

Re: [SQLObject] Unicode support

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

On Nov 9, 2003, at 8:32 AM, John Baker wrote:
> Hello,
>
> Does SQLObject have any kind of Unicode support? We seem unable to 
> find any,
> and we've put a few hacks in there to encode Strings as utf-8 before 
> they are
> placed into the database, and decodes them after they come out. It's 
> nothing
> special, but I do feel SQLObject is lacking something here.

No, there's no specific Unicode support, mostly because I'm not sure 
how they should best be encoded -- if they should be UTF-8 encoded, if 
databases have unicode literals, etc.

If you wanted to make a validator/converter to do UTF-8 encoding, it 
might look like:

from SQLObject.include import Validator
class UTF8Validator(Validator.Validator):
     def fromPython(self, v, state):
         # test isinstance(v, unicode)?
         return v.encode('UTF-8') # strict, loose?
     def toPython(self, v, state):
         return v.decode('UTF-8')

You could then use something like:

class MyThing(SQLObject):
     unicodeColumn = String(validator=UTFValidator())

I'm not entirely sure about all the details, but this pattern could 
probably be added to Col.py, and show up either as a subclass of 
String, or something that could be enabled with a keyword argument.  
(In that case it probably would be good to include other encodings, 
especially for legacy databases that don't use UTF-8, and perhaps some 
clearer handling of strict vs. loose and how to handle non-unicode 
strings)

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

[SQLObject] Unicode support

[John B. <jb...@dr...>]

Hello,

Does SQLObject have any kind of Unicode support? We seem unable to find any, 
and we've put a few hacks in there to encode Strings as utf-8 before they are 
placed into the database, and decodes them after they come out. It's nothing 
special, but I do feel SQLObject is lacking something here.


John

-- 
John Baker,
(m) 07736393822
http://rant.pointful.info

[SQLObject] 'Lost connection to MySQL server during query'

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

Hallo,

I have a problem with my Webware/SQLObject application again. :(

It's a webshop running Webware and using SQLObject. If I click like a
mad scientist on Mozilla's Reload-button I am able to crash the
Webware server. The error I get is:

...
  File "/usr/lib/python2.2/site-packages/SQLObject/DBConnection.py", line 168, in _iterSelect
    cursor.execute(query)
  File "/usr/lib/python2.2/site-packages/MySQLdb/cursors.py", line 61, in execute
    r = self._query(query)
  File "/usr/lib/python2.2/site-packages/MySQLdb/cursors.py", line 168, in _query
    rowcount = self._BaseCursor__do_query(q)
  File "/usr/lib/python2.2/site-packages/MySQLdb/cursors.py", line 112, in __do_query
    db.query(q)
OperationalError: (2013, 'Lost connection to MySQL server during query')
/home/fbar/webware/workdir/AppServer: line 9:  5395 Segmentation fault      /usr/bin/env python2.2 Launch.py ThreadedAppServer $*

This happens with using python2.2 mysqldb 0.9.1 (the Debian package)
as well as with python2.3-mysqldb 0.9.2 and SQLObject CVS or 0.5. Did
anybody here run into something like this before and/or does someone
have an idea, what to do against this? If this happens, I get stale
Webware threads, which makes automatic restarting a bit of a hassle.

ciao
-- 
 Frank Barknecht                               _ ______footils.org__

Re: [SQLObject] Enduring long queries outside SQLObject

[Randall R. <ra...@ra...>]

On Thursday, November 6, 2003, at 01:44 PM, Frank Barknecht wrote:

> Hallo,
> (And, slightly off-topic here, but I know, many here use Webware: How
> do I restart Webware's Appserver in an elegant way from inside
> Webware?)

 From a servlet (or your SitePage):
self.application().server().shouldRestart()

will tell the AppServer to restart.

--
Randall Randall
ra...@ra...

Re: [SQLObject] Enduring long queries outside SQLObject

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

Hallo,

Ian Bicking hat gesagt: // Ian Bicking wrote:
> Using 0.5 you should be able to .expire() the instances.  
> DBConnection.Transaction.rollback does this, and you could probably 
> separate that code out, maybe make an expireAll method on DBConnection 
> instances.  Ultimately that method should also find all sub-connections 
> (i.e., transactions), each of which have their own cache and set of 
> instances, but that's probably not an issue for you using MySQL.

Thank you for that tip. You're thinking about something as this: 

#####
def expireAll(Caches):
	# subCaches = [(sub, sub.allIDs()) for sub in self.cache.allSubCaches()]
	subCaches = [(sub, sub.allIDs()) for sub in Caches]
	for subCache, ids in subCaches:
		for id in ids:
			inst = subCache.tryGet(id)
			if inst is not None:
				print " -- Expiring %s\n%s" % (inst.id, inst)
				inst.expire()

x = Product(45)
y = Product(103724)
c = Product._connection.cache.allSubCaches()
expireAll(c)
######

I will try that.

ciao
-- 
 Frank Barknecht                               _ ______footils.org__