headers
Berger, Daniel | 5 Oct 2007 15:38
Favicon

Session handling busted on Oracle

Hi,

Ruby 1.8.6 (one-click)
Camping 1.5

I'd submit this as a bug, but the tracker says I'm forbidden, so here
you go.

The first problem is that the sql to create the sessions table is
broken. This is what it tried to send:

CREATE TABLE sessions (
   id NUMBER(38) NOT NULL PRIMARY KEY (38), --> Problem here
   hashid VARCHAR2(32),
   created_at DATE,
   ivars CLOB DEFAULT empty_clob()
)

The problem is that second "(38)" after "PRIMARY KEY". So, I removed
that and created the table manually.

The next problem was a missing Oracle sequence (which I had no idea was
required, but ok). I figured out (by stepping through oci8.rb) that the
name of the sequence should be "sessions_seq". For that I used the
following snippet:

CREATE SEQUENCE ACS_SUPPORT.SESSIONS_SEQ
  START WITH 50
  MAXVALUE 999999999999999999999999999
  MINVALUE 0
(Continue reading)

Permalink | Reply | 11 comments |
headers
Berger, Daniel | 5 Oct 2007 16:08
Favicon

Cookie session handling?

Hi,

I and a few folks on #camping thought it would be nice to have either
cookie based or file based session handling. This would eliminate the
need for creating a sessions table in the database (or a sequence),
which feels too heavy for a lightweight framework like Camping anyway.
Plus, we can more easily avoid nasty adapter errors. :)

The general consensus was to create a separate camping/session/cookie.rb
(or file.rb) file. That way users could include the type of session
handling they want via require + include.

require 'camping/session/cookie'

module MyCamp
   include Camping::Session::Cookie # or File, or whatever
end

Or something along those lines. Whaddya think?

Regards,

Dan

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Jonas Pfenniger | 5 Oct 2007 17:54
Picon
Gravatar

Re: Session handling busted on Oracle

Hi Daniel,

I think that I have corrected that last week changeset [226]. The
problem was that Session uses it's own kind of id (hashid) and that by
default, ActiveRecord uses an incremental version.

See : http://code.whytheluckystiff.net/camping/changeset/226

Please tell me if I introduced any regression.

--

-- 
Cheers,
  zimbatm
Permalink | Reply | 10 comments |
headers
Jonas Pfenniger | 5 Oct 2007 18:08
Picon
Gravatar

Re: Cookie session handling?

Hi Daniel,

I like the idea pretty much. What do you think of simply using a
Camping::H that is process-persistent ?

--

-- 
Cheers,
  zimbatm
Permalink | Reply | 7 comments |
headers
Julian 'Julik' Tarkhanov | 5 Oct 2007 19:27
Picon

Re: Session handling busted on Oracle


On 5-okt-2007, at 17:54, Jonas Pfenniger wrote:

> I think that I have corrected that last week changeset [226]. The
> problem was that Session uses it's own kind of id (hashid) and that by
> default, ActiveRecord uses an incremental version.
>
> See : http://code.whytheluckystiff.net/camping/changeset/226
>
> Please tell me if I introduced any regression.

I am for the proposal of having multiple session drivers, but totally  
_not_ for the proposal of abolishing
the db sessions. I routinely run Camping in parallel fashion  
(multiplexed dispatchers) and I also store
data that does not fit in the 4K cookie limit in the session (see  
Pasaporte, where the whole OpenID request
is piggybacked in the session storage). I also like the idea that all  
Camping apps store their session in _one_ record,
with many apps on one domain this would not be easily solvable  
because 4k is too small for one app, let alone many apps.
So I am for a PStore-based session but not for cookie-based sessions.  
Their introduction in Rails among others revealed some problems that
exist with this approach.

The changeset did not introduce any regressions for me but I will  
keep my Set-Cookie workaround for a while, at least until Camping 1.6  
hits the streets

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Berger, Daniel | 5 Oct 2007 22:51
Favicon

RE: Session handling busted on Oracle

> -----Original Message-----
> From: camping-list-bounces@... 
> [mailto:camping-list-bounces@...] On Behalf Of 
> Jonas Pfenniger
> Sent: Friday, October 05, 2007 9:54 AM
> To: camping-list@...
> Subject: Re: Session handling busted on Oracle
> 
> 
> Hi Daniel,
> 
> I think that I have corrected that last week changeset [226]. 
> The problem was that Session uses it's own kind of id 
> (hashid) and that by default, ActiveRecord uses an 
> incremental version.
> 
> See : http://code.whytheluckystiff.net/camping/changeset/226
> 
> Please tell me if I introduced any regression.

Doesn't work. Same error basically:

[2007-10-05 14:46:17] ERROR NoMethodError: undefined method `[]=' for
nil:NilClass

C:/ruby/lib/ruby/gems/1.8/gems/camping-1.5/lib/camping/session.rb:24:in
`[]='

C:/ruby/lib/ruby/gems/1.8/gems/camping-1.5/lib/camping/session.rb:129:in
`service'
(Continue reading)

Permalink | Reply | 8 comments |
headers
why the lucky stiff | 5 Oct 2007 23:16
Favicon
Gravatar

Re: Cookie session handling?

On Fri, Oct 05, 2007 at 06:08:12PM +0200, Jonas Pfenniger wrote:
> I like the idea pretty much. What do you think of simply using a
> Camping::H that is process-persistent ?

Sure, and maybe it doesn't really need to be process-persistent.
Yes, that would be how Camping would want us to do it.

_why
Permalink | Reply | 6 comments |
headers
Evan Weaver | 5 Oct 2007 23:54

Re: Cookie session handling?

> Sure, and maybe it doesn't really need to be process-persistent.

Wouldn't that limit you to non-load-balanced apps, since you could
only have one simultaneous process if you want session consistency?

Evan

On 10/5/07, why the lucky stiff <why@...> wrote:
> On Fri, Oct 05, 2007 at 06:08:12PM +0200, Jonas Pfenniger wrote:
> > I like the idea pretty much. What do you think of simply using a
> > Camping::H that is process-persistent ?
>
> Sure, and maybe it doesn't really need to be process-persistent.
> Yes, that would be how Camping would want us to do it.
>
> _why
> _______________________________________________
> Camping-list mailing list
> Camping-list@...
> http://rubyforge.org/mailman/listinfo/camping-list
>

--

-- 
Evan Weaver
Cloudburst, LLC
Permalink | Reply | 1 comment |
headers
Aria Stewart | 6 Oct 2007 00:06
Gravatar

Re: Cookie session handling?


On Oct 5, 2007, at 3:54 PM, Evan Weaver wrote:

>> Sure, and maybe it doesn't really need to be process-persistent.
>
> Wouldn't that limit you to non-load-balanced apps, since you could
> only have one simultaneous process if you want session consistency?
>
> Evan
>

Can always make it easy and well-defined to override. s/H/DHT with  
the right API/ and let 'em go.
Permalink | Reply | 0 comments |
headers
Jonas Pfenniger | 7 Oct 2007 18:55
Picon
Gravatar

Re: Cookie session handling?

2007/10/5, why the lucky stiff <why@...>:
> On Fri, Oct 05, 2007 at 06:08:12PM +0200, Jonas Pfenniger wrote:
> > I like the idea pretty much. What do you think of simply using a
> > Camping::H that is process-persistent ?
>
> Sure, and maybe it doesn't really need to be process-persistent.

How can it be less than process-persistent ? Instance persistent ? Or
is it irony and it means not persistent at all ? :p

--

-- 
Cheers,
  zimbatm
Permalink | Reply | 3 comments |

Gmane