[Catalyst] Session::Store::DBIC and session table (postgres)

Fernan Aguero fernan.aguero at gmail.com
Wed Nov 14 21:24:39 GMT 2012


On Wed, Nov 14, 2012 at 5:56 PM, Francisco Obispo <fobispo at isc.org> wrote:

> Use:
>
> $c->model('GUS::WebappSession') as the name.
>

And where would I put this?

I'm not dealing myself with the session data. I'm relying and delegating
all this to Session, Session::Store::DBIC, and Session::State::Cookie

That's why I'm saying that somewhere within these modules, they are failing
at getting 'GUS::WebappSession'. They seem to be using a hardwired
'sessions' table ...



> or in the config:
>
>
> <Plugin::Session>
>   dbic_class GUS::WebappSession
>   id_field id
>   storage_field session_data
>   expires_field expires
>   need_commit 0
>   expires 3600
>   verify_address 1
> </Plugin::Session>


My config is simpler, but still identical to what you propose:

[fernan at optima] cat tcsnp_local.yml
Model::GUS:
  schema_class: GUS
  connect_info:
    - dbi:Pg:dbname=3Dtcsnp
    - fernan
    - //PASS//
    - AutoCommit: 1

session:
  dbic_class: GUS::WebappSession
  cookie_name: tcsnp_cookie
  cookie_expires: 0

This is clearly not the issue.  All other SQL statements are being
generated correctly, e.g. using DBIC_TRACE=3D1

[info] tcsnp powered by Catalyst 5.90018
HTTP::Server::PSGI: Accepting connections at http://0:3006/
BEGIN WORK
SELECT me.id, me.session_data, me.expires FROM webapp.sessions me WHERE (
me.id =3D ? ): 'session:eff3bb1616f1ee3341477c4d1056c51c7ed826a6'
COMMIT
[info] *** Request 1 (0.167/s) [14993] [Wed Nov 14 18:22:13 2012] ***
[debug] Path is "genes"
[debug] "GET" request for "genes" from "127.0.0.1"
[debug] Rendering template "genes/search.tt"
[debug] Applying HTML page layout wrappers to genes/search.tt
[debug] Found sessionid "eff3bb1616f1ee3341477c4d1056c51c7ed826a6" in cookie
[debug] Response Code: 200; Content-Type: text/html; charset=3Dutf-8;
Content-Length: 25221
[info] Request took 0.331861s (3.013/s)

Here you can see that the table is fully qualified with the schema name as
expected.

It is only at the DELETE statements that this is failing.

--
fernan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20121114/6d193=
d17/attachment.htm


More information about the Catalyst mailing list