Summary:
How can we get the SQLObject team to work with the CP team to get a SQLObject sessios state adapter?
http://groups.google.com/group/turbogears/msg/5193e43f02d4b6a4
3. Kevin Dangoor Oct 21, 7:00 pm show options
From: Kevin Dangoor <dang...@gmail.com> - Find messages by this author
Date: Fri, 21 Oct 2005 22:00:07 -0400
Local: Fri, Oct 21 2005 7:00 pm
Subject: Re: [TurboGears] Re: CherryPy? 2.1 has been released
Reply | Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse
On 10/21/05, Todd Greenwood <t.greenwoodg...@gmail.com> wrote:
One of the things I'm looking at atm is the session management in
CP2.1. Looks great. One question, though. It looks like the session
backends it comes with are ram,file, and postgresql. While these are
all great options, why not just use SQLObject as the abstraction layer,
instead of requiring the consumer to write a custom backend if they
want to use a different database, etc?
Actually, if you look at this page:
http://www.cherrypy.org/wiki/SessionFilter
you'll see that someone started an SQLObject backend but didn't finish
it. There was a ticket opened that said that there was some complexity
involved:
http://www.cherrypy.org/ticket/220
Perhaps this is part of a larger question. TG is an aggregator of other
technologies, and the underlying components may not share the same
overall philosophy as this project. For example, here it seems that CP
doesn't share the same abstraction of SQLObject as the data store.
My philosophy is that we do what we need to do to get the
functionality we need to have. Under ideal, and likely, circumstances
we'll get the functionality rolled into the other projects and keep
TurboGears itself pretty slim. We get to leverage a much larger
community that way.
But, any code that is specific to the combination of tools we have,
we'll likely just have to own it in this project.
In short: build the features we need, possibly starting their life in
TurboGears, but move those features into the core projects as much as
possible.
Does this mean that TG is going to own abstracting the session backend?
Or is this one of those grey areas where the community will have to
fend for itself?
Maybe the thing to do here is to open a ticket in our Trac that
references the CherryPy? ticket, since we're the ones most likely to
care about such a thing.
Kevin
--
Kevin Dangoor
Author of the Zesty News RSS newsreader
email: k...@blazingthings.com
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com
Reply
4. Todd Greenwood Oct 21, 10:35 pm show options
From: "Todd Greenwood" <t.greenwoodg...@gmail.com> - Find messages by this author
Date: Fri, 21 Oct 2005 22:35:02 -0700
Local: Fri, Oct 21 2005 10:35 pm
Subject: Re: CherryPy? 2.1 has been released
Reply | Reply to Author | Forward | Print | Individual Message | Show original | Remove | Report Abuse
Looks a bit sticky. As mikerobi has stated that it's a wontfix due to
complexity and that 'sqlobject is not 100% thread safe'. Perhaps we
should get the SQLObject folks to talk to the CP folks?
-Todd
Mon 22 Aug 2005 03:25:22 PM CDT: Modified by mikerobi
- resolution set to wontfix
- status changed from assigned to closed
An sqlobject adaptor requires uneccessary complexity do to convertion
to and from python dictionarys. The sqlobject adaptor has been dropped.
A driver based on PyDO2 will take its place. (I am not against
including an sqlobject adaptor if someone else would like to contribute
it, but I suggesting waiting till after I release the PyDO adaptor, so
you can see how column names are handled.)
