sqlobject-discuss — All things SQLObject-related

[SQLObject] SQLObject slides

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

I made a SQLObject presentation a couple weeks ago, the slides are in 
the repository, or online:

http://ianbicking.org/docs/sqlobject-presentation/sqlobject-and-database-programming.html

I don't really recommend reading them, they aren't that interesting; 
slides generally aren't, and they probably don't have a lot of new ideas 
for anyone who has used SQLObject much at all.  But I thought I'd note 
the existance; if anyone wants to do a SQLObject presentation, they 
should feel free to use and modify the slides however they want.

Incidentally, the slides are written with s5:
   http://www.meyerweb.com/eric/tools/s5/
It's an HTML/javascript slideshow system, and very easy to use (at least 
if you know HTML).

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

Re: [SQLObject] Re: DB API

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

On Mon, Nov 29, 2004 at 10:24:26AM -0600, Ian Bicking wrote:
> I generally thing this is the right thing to do.

   Now, when I've commited almost all patches related to inheritance, I
am going to work on it in another private branch.

> The first two problems could be solved with a nice abstraction.  I'd 
> like something like __sqlrepr__, but it could return the abstraction 
> instead of a text SQL literal.

   This is exactly what I've proposed. We agree on it. Fine!

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

Re: [SQLObject] Re: DB API

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

Oleg Broytmann wrote:
> On Mon, Nov 22, 2004 at 03:14:41PM +0300, Oleg Broytmann wrote:
> 
>>   Why use sqlStringReplace and _[lL]ikeQuoted?...
>>   ...use format/pyformat/etc paramstyle from DB API 2.
> 
>    But this, probably, requires some architectural changes in the
> SQLObject.
>    Well, what do you think of this?

I generally thing this is the right thing to do.  There are a couple 
reasons it wasn't that way originally:

* I wanted to be able to override SQL representation, with what is now 
__sqlrepr__.
* Constructing SQL from several sources is difficult when you have to 
worry about the order of parameters.
* There's no standard paramstyle.

Going backwards through the list...

The standard paramstyle probably isn't that big a deal.  %s is an easy 
implementation (just do query % ('?', '?', ...) or whatever); pyformat 
doesn't imply SQL parsing in the way other formats (like ?) do; you have 
to escape any %'s.  The other way would be the split strings.  I think 
named and numeric both imply SQL parsing, and as such are too difficult. 
  When this last came up on DB-SIG, I gave several examples where 
parsing would be necessary:
   http://mail.python.org/pipermail/db-sig/2004-August/004165.html

And it is even worse than that, because aspects of the parsing are 
database specific (like string quoting), and we're back to where we 
started, but with more code.


The first two problems could be solved with a nice abstraction.  I'd 
like something like __sqlrepr__, but it could return the abstraction 
instead of a text SQL literal.  Maybe this query abstraction would 
contain the list of parameters, and a list of strings (where parameters 
go inbetween the strings).  There'd be a method to convert the query 
object to a SQL string with the appropriate paramstyle, and a list of 
parameters.  The query objects would also support concatenation. 
__sqlrepr__ would take a bit of thought, but if the method was present 
it should allow a parameter to insert new text and new parameters. 
E.g., a Point object might look like:

class Point:
   def __init__(self, x, y):
       self.x, self.y = x, y
   def __sqlrepr__(self):
       return ('(', ', ', ')'), (self.x, self.y)
       # or...?
       return '(%s, %s)', (self.x, self.y)

The first is hard to read, the second requires a standard simplistic 
paramstyle (like pyformat).  Potentially both could be supported.

All of this could be SQLObject-neutral.  I don't think it would be quite 
as intuitive as string substitution, but hopefully it could get close. 
Since people are frequently proposing these sorts of libraries (often 
under the guise of DB API 3), maybe it's all much harder than I realize. 
    But maybe

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

Re: [SQLObject] "SQLCall instance" instead of actual values

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

Justin Azoff wrote:
> I just reworked an app using sqlobject-0.6 to use a single connection to
> the backend, and to hand out objects converted to dictionaries using
> xmlrpc.  This was mostly to enable caching on the db and to simplify a
> few things.
> 
> but now, after the first few requests I start to get errors like:
> 
> File "/tmp/sqlscanner/scandb.py", line 361, in scanasdict
>     st=int(s.starttime)
> exceptions.AttributeError: SQLCall instance has no attribute '__int__'
> 
> where that function is:
> def scanasdict(s):
> ...
>     if s.starttime:
>         st=int(s.starttime)
>     else :
>         st=0
> ...
>     scan={
>         "id": s.id,
>         "ip": s.ip,
> ...
>         "starttime": st,
> ...
>     return scan
> 
> and starttime is simply a DateTimeCol that can be NULL.
> 
> What could be causing a SQLCall instance to be returned instead of a
> date, and how can I fix that?

This is a bug when using sqlbuilder.func.NOW(), like:

s.set(starttime=sqlbuilder.func.NOW())

I'm not sure what to do about this right now, in a general sense.  I'd 
recommend using DateTime.now() instead.

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

Re: [SQLObject] .set() fromPython

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

Oleg Broytmann wrote:
> Method SQLObject.set(), lines 769-774:
> 
>         if self._SO_creating or self._lazyUpdate:
>             for name, value in kw.items():
>                 fromPy = getattr(self, '_SO_fromPython_%s' % name, None)
>                 if fromPy:
>                     kw[name] = value = fromPy(value, self._SO_validatorState)
>                 setattr(self, instanceName(name), value)
> 
> Method SQLObject.set(), lines 793-801:
> 
>             for name, value in kw.items():
>                 fromPython = getattr(self, '_SO_fromPython_%s' % name, None)
>                 if fromPython:
>                     dbValue = fromPython(value, self._SO_validatorState)
>                 else:
>                     dbValue = value
>                 toUpdate[name] = dbValue
>                 if self._cacheValues:
>                     setattr(self, instanceName(name), value)
> 
> In the first snippet the value is converted from Python to db value and
> assigned to the attribute named "name". In te second snippet in is not
> converted; instead, new variable dbValue holds convertd value, and the
> attribute "name" receives original, "pythonic" value.
>    Isn't there a bug in the first snippet? Shouldn't it be
> 
>                     kw[name] = dbValue = fromPy(value, self._SO_validatorState)
>                 setattr(self, instanceName(name), value)
> 
>    ? I am not sure how special _SO_creating is...

Yes, you are correct.  _SO_creating doesn't really matter one way or the 
other here.  I've committed the fix you propose.

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

Re: [SQLObject] ._create() and .set()

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

Oleg Broytmann wrote:
> SQLObject._create() performs separation of values based on
> self._SO_plainSetters, creating "forDB" and "others", and calling
> self.set(**forDB).
> 
>    Is the separation really neccessary? self.set() does the same
> separation itself. Why not just pass all values to self.set()?

I think you're right, there's no real reason for this split.  It 
probably is left over from a (much) earlier time when the code didn't 
use .set while doing inserts (before _SO_creating).

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

[SQLObject] Patches

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

Hello!

   I've commited two patches from SF tracker: DATE type for sqlite, and
MySQL "DOUBLE PRECISION" for FloatCol at revision 411, and merged them
into inheritance branch at 412.

   I don't have rights to close these patches. Please close all 3 (there
is a dup there).

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

[SQLObject] Inheritance: documentation and a test case

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

Hello!

   I've commited documentation (actually, a modified version of Daniel's
description) and a test case, based on the example in his text:

http://svn.colorstudy.com/home/phd/SQLObject/inheritance/docs/Inheritance.txt

   I am not good at writing reST, so the doc almost certainly will have
problems converting to HTML. I'll work on it.

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

Re: [SQLObject] Three Tier apps

[Dave W. <da...@su...>]

Another option for going multi tier is rather than specifically extend 
sql object to create something like http://c-jdbc.objectweb.org/ for 
pythons db api.

This way you can have a whole extra level between sqlObject and the 
database server. Not one to add logic but definitely one to add db 
independence, db scaling and db fault tolerance. But it would be 
something that would work for any db access from python.

Personally I would like to suggest a multi-tier approach based on the 
following

Client --REST--> queue server

Middle Tier --REST--> queue server

Middle Tier --db aggregator--> database server

But included in this will be intra middle tier communication also via 
the queue server to parcel up large tasks into smaller concurrent ones.

Take for example some complex reporting requirement. The client (be it 
web browser or gui) puts a single request in the queue. A middle tier 
server collects the request and does a spread out thus putting many much 
smaller requests into the queue which it will aggregate together to 
create the final report. Each of these smaller requests is picked up by 
a middle tier server (remember you can have as many of these as you 
want) and it is here sqlObject would be used. By connecting the 
sqlObject calls through an aggregator the db queries can be executed in 
parallel on multiple db servers.

Once the original client has submitted the request it simply polls the 
queue server to check on progress.

Now this is quite different architecturally to what you were thinking 
of. However, I would like to suggest that it is also more flexible and 
more likely to succeed. Why?

a) All the components needed (Queue Server, db aggregator) benefit 
multiple projects. So you can get wider support than developing a 
solution for just sqlObject where your total community will always be 
smaller than the sqlObject community.

b) It gives you far more flexibility. Suppose you find that one task 
element that you put in the queue would be much easier to write without 
sqlObject. You don't lose any of the tiers when you need to do this.

c) It gives much better scaling. You can add more middle tier servers, 
more database servers at will. You can also take better advantage of 
multi-processor machines with Python by running multiple python middle 
tier servers on a single multi-processor server. This avoids the GIL 
issues with multi-threaded python code - well it also avoids loads of 
threading issues.

d) You might lose out with sqlObject caches although you can get sql 
caching in the aggregator. But you could also add middle-tier affinity 
to tasks so that certain items in the queue are most likely to be picked 
up by the middle tier server which is most likely to have the most 
useful cache.

e) It also gives the huge flexibility of being able to migrate tools and 
language. Suppose one task is much better suited to Ruby or to some 
other db layer in Python. Now you can have a separate middle tier server 
that will pick up those types of task. You have no dependency issues as 
all that communication is done via REST.

f) This approach also gives you Internet scale. You can distribute your 
middle tier servers anywhere on the Internet. So for example they can be 
local to the database or other resource they need to use. Or to provide 
fault tolerance.

g) Lastly it should, with care, be possible to adopt an architecture 
like this that will scale from a single user, single PC (queue server, 
middle-tier and db all inside a single python process) to almost any scale.

Sorry if this is considered too off subject.

Regards

Dave
-- 
Dave Warnock: http://42.blogs.warnock.me.uk

[SQLObject] Table inheritance

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

Hello!

   I have created a private branch to play with table inheritance , and
commited a first patch:

   http://svn.colorstudy.com/home/phd/SQLObject/inheritance/

The patch contains changes to sqlobject/main.py. Documentation and test
suite will follow.

   IWBN if people who are interested in table inheritance start using
and testing this version.

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

RE: [SQLObject] Three Tier apps

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

>I'm not sure I understand what you want to do. Do you want to be able to 
>instantiate SQLObjects (by ID?) on both sides of the network connection? 
>Would that not be contrary to isolating functionality into separate layers?

Tier 1 - Gui,wxPython or curses or html of some sort

- connects with pyro remoteing to -

Tier 2  - Business logic, SQLObject

- connects with psycopg to-

Tier 3 - Persistant storage, Postgresql

Any tier 2 -> tier 3 communicaton will occur within the context of a single
transaction, so Pyro is safe to handle pickles that contain
less-than-complete object representations, as tier 3 has exclusive control
of the external data at that point.

To clarify the business logic futher-

In addition to the standard create, read, update, and delete methods you
would normally expect to perform on objects, I have other methods that
perform complex logic specific to my application. 

Currently I have three logical layers, but tier 1 and 2 both are in the
client application. Physically, it's a two tier system.

I want to break out the business logic onto a middleware server, so the
client and  middleware will need a network protocol to tie them together.
Pyro or ICE are the two candidates, but pyro seems more Pythonic. 

Re: [SQLObject] is SQLObject.new() gone?

[Michel T. <mic...@ya...>]

Hi Paul

If you are using 0.6 version, you should override the "_create" method.
I.E.:

def _create(self, id, **kw):
  content=kw.pop('content')
  SQLObject._create(self, id, **kw)
  self.content=content


 --- paul kölle <pa...@su...> escreveu: 
> Hi,
> 
> following this tread:
>
http://sourceforge.net/mailarchive/forum.php?forum_id=30269&style=flat&viewday=15&viewmonth=200312
> 
> I did override the new method of my classes to set up attributes 
> beforehand like so:
> 
> def new(cls, **kw):
>      dostuff_here()
>      ....
>      return super(MyClass, cls).new(**kw)
> 
> new = classmethod(new)
> 
> Having upgraded python (from 2.2 to 2.3) and probably sqlobject (not 
> sure cause I used svn before... now its what gentoo calls 0.6) the
> above 
> broke my app.
> 
>    File "/mnt/data/projects/pki/certs.py", line 189, in new
>      obj = super(CertItem, cls).new(**kw)
> AttributeError: 'super' object has no attribute 'new
> 
> It looks like the SQLObject class has no new() method anymore ;(. Is 
> there a way to get this functionality back? Do I have to override 
> __init__ now? (I recall having read to not doing so, but it seems 
> natural since instances are now created like inst = SQLObject(**kw))
> 
> thanks
>   Paul
> '
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real
> users.
> Discover which products truly live up to the hype. Start reading now.
> 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>  

=====
--
Michel Thadeu Sabchuk
Curitiba/PR


	
	
		
_______________________________________________________ 
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/

[SQLObject] is SQLObject.new() gone?

[<pa...@su...>]

Hi,

following this tread:
http://sourceforge.net/mailarchive/forum.php?forum_id=30269&style=flat&viewday=15&viewmonth=200312

I did override the new method of my classes to set up attributes 
beforehand like so:

def new(cls, **kw):
     dostuff_here()
     ....
     return super(MyClass, cls).new(**kw)

new = classmethod(new)

Having upgraded python (from 2.2 to 2.3) and probably sqlobject (not 
sure cause I used svn before... now its what gentoo calls 0.6) the above 
broke my app.

   File "/mnt/data/projects/pki/certs.py", line 189, in new
     obj = super(CertItem, cls).new(**kw)
AttributeError: 'super' object has no attribute 'new

It looks like the SQLObject class has no new() method anymore ;(. Is 
there a way to get this functionality back? Do I have to override 
__init__ now? (I recall having read to not doing so, but it seems 
natural since instances are now created like inst = SQLObject(**kw))

thanks
  Paul
'

Re: [SQLObject] SQLObject and Zope 2.7.3/2.8.0a1

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

On Fri, Nov 26, 2004 at 06:03:14PM +0100, Anders Bruun Olsen wrote:
> WHOA! It seems I fixed it!
[skip]
> Backend.People.setConnection and so forth in my main class's __init__. I

   Congratulations!

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

[SQLObject] Minions of Mirth: Open Source RPG using SQLObject

[Josh R. <jr...@pr...>]

Greetings...

My name is Josh Ritter and I am a veteran game programmer working on an =
Open Source RPG, called "Minions of Mirth". The engine is also Open =
Source and features some really cool technology.  The game currently =
runs on Windows and OSX.

We are using SQLObject in conjunction with Twisted for persistence, =
security, and management of our distributed game servers. =20

Please see the "Barrage o' Links" below for an 8 minute video and =
playable demo/test for Windows and OSX.  We are very interested in =
collaborating with others on Open Source games and technology...

I hope you find this an interesting use of SQLObject!!!!  Thank you and =
keep up the great work!!!

Vibes!
-Josh Ritter
Technical Director
http://www.prairiegames.com

Barrage o' Links:

Our webpage is http://www.prairiegames.com

There is an 8 minute gameplay movie linked here:
http://www.prairiegames.com/games.html

There are additional screenshots and content samples here:
http://www.prairiegames.com/phpBB2/viewforum.php?f=3D9

There is an interactive compatibility test here:
http://www.prairiegames.com/phpBB2/viewforum.php?f=3D11

Prairie Engine:
http://sourceforge.net/projects/prairieengine/

OpenSRD Third Edition Rules Implementation:
http://sourceforge.net/projects/opensrd

Dedicated Open Source SRD 3.5 Implementation Forum
http://www.prairiegames.com/phpBB2/viewforum.php?f=3D12

About Prairie Games, Inc:

Prairie Games Inc is an independent game company with offices in North =
Dakota and Los Angeles. With 12 shipped retail games to our staff =
credit, we are dedicated to making fun and entertaining role-playing =
games. Our games and technology are Open Source to allow the greatest =
amount of creative exchange with other developers.

Re: [SQLObject] Three Tier apps

[Alan K. <sql...@xh...>]

[jwsacksteder]
> I'm considering what it takes to extend SQLObject to a three tier
> configuration. The leading candidate is Pyro, which uses pickle to pass
> around proxy remote objects. If SQLObject is in the middle tier containing
> all the business logic, is it possible to handle SQLObjects in this way? I
> believe there are 'pickle issues'?

You may be interested in a snippet I sent to the list last month which 
pickles references to SQLObjects.

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

The original question I posed, about how to pickle SQLObjects using 
__getstate__ and __setstate__ (which doesn't work), can be found here

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

Using the above snippet, I'm fairly sure that you could communicate 
references to SQLObjects back and forth across a socket through pickles.

As for Pyro, a search through the 3.3 codebase for "persistent_id" and 
"persistent_load" turns up nothing, so I imagine that Pyro would require 
some changes to support pickling external objects. But I think Irmen is 
pretty open to those kinds of things. You can read about the pickle 
extensions for pickling references to external objects here

http://docs.python.org/lib/node69.html

I'm not sure I understand what you want to do. Do you want to be able to 
instantiate SQLObjects (by ID?) on both sides of the network connection? 
Would that not be contrary to isolating functionality into separate layers?

Regards,

Alan.

Re: [SQLObject] SQLObject and Zope 2.7.3/2.8.0a1

[Anders B. O. <an...@br...>]

On Fri, Nov 26, 2004 at 07:39:48PM +0300, Oleg Broytmann wrote:
>    Ouch! I am not sure about what caused this. My guess is that Zope or
> ZODB cannot unpickle connection object. I am not sure if it is possible
> to fix the problem. This is probably that "pickle problem" - SQLObject
> tables are essentially non-picklable, I am afraid.

WHOA! It seems I fixed it!
I have in my Backend.py file not set a _connection for any of my
SQLObject classes because I want to define that information directly
when adding the object to Zope, and I then set it with
Backend.People.setConnection and so forth in my main class's __init__. I
thought I would give this one simply try to see if it was indeed just a
question of restoring the connection (and without knowing whether
sqlobject would indeed do what I thought it would do). I moved those
.setConnection calls into a method of it's own that is called from
__init__ but also from the methods that actually fetch information from
SQLObject right before instantiating any SQLObject classes, and it
bloody well survives both Zope restarts AND product refreshes now!
I know that it might be quite an evil punch in the gut of performance
for my app, but so far it is only a few people on our LAN that will use
it to interact with a few databases. Later when I need to integrate
those databases with a Plone site I can give some more consideration to
performance and see if it does indeed hurt performance to reconnect to
the db on every db-related-action.
Since most normal webapps do one db-connection per page load and this
will be almost the same I don't really think it will be that bad
performance-wise.

-- 
Anders
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/O d--@ s:+ a-- C++ UL+++$ P++ L+++ E- W+ N(+) o K? w O-- M- V
PS+ PE@ Y+ PGP+ t 5 X R+ tv+ b++ DI+++ D+ G e- h !r y?
------END GEEK CODE BLOCK------
PGPKey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8BFECB41

Re: [SQLObject] SQLObject and Zope 2.7.3/2.8.0a1

[Anders B. O. <an...@br...>]

On Fri, Nov 26, 2004 at 07:39:48PM +0300, Oleg Broytmann wrote:
> > Same problem. Whenever Zope has been stopped my product breaks as I have
> > described, and it needs to be added again. I have tried with "Restart"
> > in the Zope panel and actually stopping the Zope service on the server
> > and starting it again.
>    Ouch! I am not sure about what caused this. My guess is that Zope or
> ZODB cannot unpickle connection object. I am not sure if it is possible
> to fix the problem. This is probably that "pickle problem" - SQLObject
> tables are essentially non-picklable, I am afraid.

Damn.. oh well, I guess it's I'm gonna have to use the MySQLdb module
and do the SQL manually then :-/.
Since I was planning to first learn Zope and then get a Plone site up
and running for work and then integrate a few databases we have in there
through Zope/Plone products, it isn't just possible for me to use
something like Webware instead (which I believe I read somewhere runs
sqlobject just fine). I'll have to do the manual work for now since
Plone doesn't run on Zope3 yet and Zope3 seems quite a bit different
from Zope2.

Anyways, thank you for your help!

-- 
Anders
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/O d--@ s:+ a-- C++ UL+++$ P++ L+++ E- W+ N(+) o K? w O-- M- V
PS+ PE@ Y+ PGP+ t 5 X R+ tv+ b++ DI+++ D+ G e- h !r y?
------END GEEK CODE BLOCK------
PGPKey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8BFECB41

Re: [SQLObject] Three Tier apps

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

On Fri, Nov 26, 2004 at 11:24:46AM -0500, jws...@ra... wrote:
> I'm considering what it takes to extend SQLObject to a three tier
> configuration. The leading candidate is Pyro, which uses pickle to pass
> around proxy remote objects. If SQLObject is in the middle tier containing
> all the business logic, is it possible to handle SQLObjects in this way? I

   Why do you want to pickle SQLObject tables?

> believe there are 'pickle issues'?

   It seems there are.

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

Re: [Fwd: Re: [SQLObject] SQLObject and Zope 2.7.3/2.8.0a1]

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

On Fri, Nov 26, 2004 at 09:55:07AM -0600, Nick wrote:
> > > > Ahh.. and .select() returns None, and the list(p) then fails because
> > > > list(None) does not make sense, since None is not iterable.
> > 
> > list(p or ())

   Wrong solution. The real problem is that Zope had lost connection.
One needs to restore the connections for all tables.

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

Re: [SQLObject] SQLObject and Zope 2.7.3/2.8.0a1

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

On Fri, Nov 26, 2004 at 04:54:14PM +0100, Anders Bruun Olsen wrote:
> >    Do not use refresh. Always do full Zope restart - stop and start it
> > anew.
> 
> Same problem. Whenever Zope has been stopped my product breaks as I have
> described, and it needs to be added again. I have tried with "Restart"
> in the Zope panel and actually stopping the Zope service on the server
> and starting it again.

   Ouch! I am not sure about what caused this. My guess is that Zope or
ZODB cannot unpickle connection object. I am not sure if it is possible
to fix the problem. This is probably that "pickle problem" - SQLObject
tables are essentially non-picklable, I am afraid.

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

[SQLObject] Three Tier apps

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

I'm considering what it takes to extend SQLObject to a three tier
configuration. The leading candidate is Pyro, which uses pickle to pass
around proxy remote objects. If SQLObject is in the middle tier containing
all the business logic, is it possible to handle SQLObjects in this way? I
believe there are 'pickle issues'?

[Fwd: Re: [SQLObject] SQLObject and Zope 2.7.3/2.8.0a1]

[Nick <ni...@dd...>]

I think a polite note to tell me that I had accidentally hit "reply"
instad of "reply all" would have nicer.  I sincerely apologize that you
got hit, as I didn't reply to the original message but the latest I saw
in the thread.

Unfortunately I deleted the original messages already, so I'm not sure
of the context of the reply anymore (I've since read over 100 messages
in my inbox this morning), but if you are in a situation where you need
a list but the result may be None instead of a list, you can indeed use
list(x or ()) where x is either an iterable or None.  () is slightly
faster as a literal than [].

Nick

-------- Forwarded Message --------
From: Oleg Broytmann <ph...@ph...>
Reply-To: Oleg Broytmann <ph...@ph...>
To: Nick <ni...@dd...>
Subject: Re: [SQLObject] SQLObject and Zope 2.7.3/2.8.0a1
Date: Fri, 26 Nov 2004 18:27:04 +0300
On Fri, Nov 26, 2004 at 09:21:13AM -0600, Nick wrote:
> On Fri, 2004-11-26 at 14:36 +0300, Oleg Broytmann wrote:
> > > Readability. I like list() because it seems just a tiny bit more clear
> > > than [], even though the end result is the same.
> > 
> >    Oops. My readability taste says opposite! :) I prefer [] to list().
> > The matter of taste...
> > 
> > > > > According to the errorlog the error occurs on the line where I do the
> > > > > for-loop, which means that the problem is the list(p) call. I am
> > > >    No. .select() cannot find a module or class.
> > > 
> > > Ahh.. and .select() returns None, and the list(p) then fails because
> > > list(None) does not make sense, since None is not iterable.
> 
> list(p or ())

   Don't send my private messages, please. At least do Cc to the list.
BTW, I'm not the person with the problem... and anyway your solution is
wrong.

Oleg.
-- 

Re: [SQLObject] SQLObject and Zope 2.7.3/2.8.0a1

[Anders B. O. <an...@br...>]

On Fri, Nov 26, 2004 at 02:36:07PM +0300, Oleg Broytmann wrote:
> > Readability. I like list() because it seems just a tiny bit more clear
> > than [], even though the end result is the same.
>    Oops. My readability taste says opposite! :) I prefer [] to list().
> The matter of taste...

Yup! :)

> > Ahh.. and .select() returns None, and the list(p) then fails because
> > list(None) does not make sense, since None is not iterable.
>    Clear, but not exactly. .select() returns SelectResult, whose
> __iter__ returns iterSelect of its dbconnection. It seems connection
> object was broken or lost during refresh.

Okay.

> > >    No, this is due to problems with registries. SQLObject registries are
> > > not compatible with module reloading (refresh).
> > Hmm.. and I assume there is no easy way to fix that?
>    Do not use refresh. Always do full Zope restart - stop and start it
> anew.

Same problem. Whenever Zope has been stopped my product breaks as I have
described, and it needs to be added again. I have tried with "Restart"
in the Zope panel and actually stopping the Zope service on the server
and starting it again.

-- 
Anders
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/O d--@ s:+ a-- C++ UL+++$ P++ L+++ E- W+ N(+) o K? w O-- M- V
PS+ PE@ Y+ PGP+ t 5 X R+ tv+ b++ DI+++ D+ G e- h !r y?
------END GEEK CODE BLOCK------
PGPKey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8BFECB41

[SQLObject] ._create() and .set()

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

SQLObject._create() performs separation of values based on
self._SO_plainSetters, creating "forDB" and "others", and calling
self.set(**forDB).

   Is the separation really neccessary? self.set() does the same
separation itself. Why not just pass all values to self.set()?

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