Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #66 (closed defect: wontfix)

Opened 14 years ago

Last modified 10 years ago

Need SQLObject session storage driver in CP

Reported by: GreanTea Owned by: anonymous
Priority: high Milestone:
Component: TurboGears Version: 0.9a6
Severity: normal Keywords:
Cc:

Description

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

  1. Kevin Dangoor Oct 21, 7:00 pm show options

From: Kevin Dangoor <dang...@…> - 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...@…> 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...@… company:  http://www.BlazingThings.com blog:  http://www.BlueSkyOnMars.com

Reply

  1. Todd Greenwood Oct 21, 10:35 pm show options

From: "Todd Greenwood" <t.greenwoodg...@…> - 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.)

Change History

comment:1 Changed 14 years ago by kevin

  • Priority changed from normal to high

comment:2 Changed 13 years ago by khorn

  • Milestone 0.8 deleted

milestone has passed, removing milestone

is this still a problem?

comment:3 Changed 13 years ago by jorge.vargas

  • Milestone set to __future__

comment:4 follow-up: ↓ 5 Changed 11 years ago by Chris Arndt

  • Component changed from CherryPy to TurboGears

It doesn't look like a SO-based session storage is going to happen. The question is whether we want to build one based on SQLAlchemy instead now, or do we want to implement a session handling based on the visit framework, or can we utilize a wsgi session handler in TG 1.5 / CP3?

comment:5 in reply to: ↑ 4 Changed 10 years ago by jorge.vargas

  • Status changed from new to closed
  • Resolution set to wontfix

Replying to Chris Arndt:

It doesn't look like a SO-based session storage is going to happen. The question is whether we want to build one based on SQLAlchemy instead now, or do we want to implement a session handling based on the visit framework, or can we utilize a wsgi session handler in TG 1.5 / CP3?

I agree with this, no one is interested in a SO based session storage, if we are going to work on a SA one it should be a separate ticket.

comment:6 Changed 10 years ago by anonymous

  • Milestone __future__ deleted

Milestone future deleted

Note: See TracTickets for help on using tickets.